On Mon, Apr 27, 2020 at 3:57 PM Andrea Faulds <a...@ajf.me> wrote: > Hi, > > I share Dan's reasons for voting against. I don't think things should go > to a vote before the dust has settled. > > Regards, > Andrea Faulds >
Similar sentiment here. I don't think the concept has been explored sufficiently. Many people in the voting thread are calling for supporting match expressions only (without support for either statement form, or support for block expressions). The RFC motivates the match construct as an improved replacement for switch, which is type-safe, exhaustive and has no fallthrough gotchas. If we limit match to returning simple expressions only, is it still a viable replacement for switch? I've looked at a sample of ~50 switches randomly picked from popular composer packages, the list can be found here: https://gist.github.com/nikic/fc225f02ea76c02e669a598cfc471b83 I've classified these according to whether the switches could be rewritten as a match if it only supports expression, but not statement form. What I was looking for here was the ability to more or less directly translate, without having to do major refactoring first. Results: 2595: no (only with block expression support) 8337: no (only with block expression support) 2115: no 7109: no (only with block expression support) 6564: no 7786: no (only by returning a pair, and only realistic with block expression support) 2609: yes 7450: no (only by returning a triple, and only with block expression support) 5338: no 567: no 3376: yes (but weird stylistically) 2850: no 2635: yes 61: no 6562: no 2354: yes 522: no 4972: yes 8179: no 6080: yes 5997: yes 6758: yes 6718: no (only with block expression support) 1451: maybe 9152: yes 4192: no 4099: no 6773: yes 2727: yes (but weird stylistically) 6779: yes 2710: no 149: yes 7501: no 1197: no (only with block expression support) 6845: yes 6610: no 1088: yes (but weird stylistically) 2806: yes 3393: no 8361: no (only by returning a pair, and only with block expression support) 4473: no 8543: no 8792: no (only with block expression support, maybe) 8776: no 1165: yes 8388: yes 8294: no 3840: yes 3587: yes 6428: (empty switch) 8324: no 1280: no 2023: yes 8084: no (maybe with block expression support) Of the switches I looked at, 31 cannot use match in single-expression form, while 21 can. Is match intended as a replacement for switch? Or is intended to replace the ternary operator? Do we want people to be able to convert switches to matches without much hassle, or is this only intended for a specific subset? I'm not quite clear on what "match" is intended to be, and I think different people in this discussion have rather different views on this. Regards, Nikita
