On Tue, Jul 23, 2024 at 9:06 AM Larry Garfield <la...@garfieldtech.com> wrote:
> On Tue, Jul 23, 2024, at 1:42 PM, Matthew Weier O'Phinney wrote: > > On Fri, Jul 19, 2024 at 12:41 PM Gina P. Banyard <intern...@gpb.moe> > wrote: > >> Hello internals, > >> > >> I have opened the vote for the mega deprecation RFC: > >> https://wiki.php.net/rfc/deprecations_php_8_4 > >> > >> Reminder, each vote must be submitted individually. > >> > >> > >> Best regards, > >> > >> > >> Gina P. Banyard > > > > > > The section "Deprecate using a single underscore ''_'' as a class name" > > indicates that probably the primary reason to deprecate it is a > > potential future conflict in the pattern matching RFC, where it can be > > used as a wildcard. > > > > However, I see no mention of this character as a wildcard anywhere in > that RFC. > > > > Can somebody clarify? > > The pattern matching RFC previously listed _ as a wildcard character. > > In the discussion a month ago, someone pointed out that `mixed` already > serves that exact purpose, so having an extra wildcard was removed. > > However, a few people indicated a desire to have an explicit wildcard _ > anyway, even if it's redundant, as it's a more common and standard approach > in other languages. We've indicated that we are open to making that an > optional secondary vote in the pattern matching RFC if there's enough > interest (it would be trivial), though I haven't bothered to add it to the > RFC text yet. > > Having _ available could also be used in other "wildcard" or "ignore this" > cases, like exploding into a list assignment or similar, though I don't > believe that has been fully explored. > Can you provide examples of what that usage would look like? And the question I have really is, does this actually _require_ using "_", or could another token be used for such matches? -- Matthew Weier O'Phinney mweierophin...@gmail.com https://mwop.net/ he/him
