Another situation in which _ might be useful. match (_) { ... }
On Mon, 14 Dec 2020, 21:43 Marco Pivetta, <ocramius@gmail.com> wrote:
> Hey Doug,
>
>
>
>
> On Mon, Dec 14, 2020, 21:24 Doug Nelson <dougnelson@silktide.com> wrote:
>
> > Hi Marco,
> >
> > Is there any chance you can elaborate on why you feel it's a bad idea?
> >
> > Both you and Sara at different points have talked about thinking was bad
> > practice, but I've not read anything compelling about why it should be
> > considered as such.
> >
> > Kind regards,
> > Doug Nelson
> >
> > On Mon, 14 Dec 2020 at 18:14, Marco Pivetta <ocramius@gmail.com> wrote:
> >
> >> Hey Larry,
> >>
> >> On Mon, Dec 14, 2020 at 6:34 PM Larry Garfield <larry@garfieldtech.com>
> >> wrote:
> >>
> >> > I present to Internals this tiny RFC to follow up on the match()
> >> > expression RFC from earlier in the year. There was solidly positive
> >> > support for this shortcut previously but it was removed for simplicity
> >> at
> >> > the time, with the intent to bring it back later. It's now later.
> >> >
> >> > https://wiki.php.net/rfc/short-match
> >> >
> >>
> >> Overall back to the switch (true) case, which IMO is not a good idea
> in
> >> first place :|
> >>
> >> Nothing wrong with using a set of conditional that are put in a sequence
> >> through if (), for these rare cases.
> >>
> >> Marco Pivetta
> >>
> >> http://twitter.com/Ocramius
> >>
> >> http://ocramius.github.com/
> >>
> >
> >
> > --
> > Doug Nelson
> > Senior Software Engineer
> >
>
>
> It's effectively yet another way to write something that already exists,
> which means more syntax to learn, more syntax to deal with (in downstream
> tooling), and that for an edge case being a fall-through list of boolean
> expressions, which is what already happens by using if with early return
> statements.
>
> Let me rephrase it then:
>
> * It brings little to no advantage to the table for something seen very
> rarely (match already being super-rare, since adoption didn't even start
> yet)
> * It increases language complexity
>
> Every time new AST is to be added, that complexity needs to be weighed
> against the benefits, and I don't see any compelling ones here.
>