Re: [RFC] [VOTE] Deprecations for PHP 8.4

From: Date: Tue, 23 Jul 2024 14:54:30 +0000
Subject: Re: [RFC] [VOTE] Deprecations for PHP 8.4
References: 1 2 3 4  Groups: php.internals 
Request: Send a blank email to [email protected] to get a copy of this message
On Tue, Jul 23, 2024, at 2:41 PM, Christoph M. Becker wrote:
> On 23.07.2024 at 16:04, Larry Garfield 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 <[email protected]> wrote:
>>>
>>>> I have opened the vote for the mega deprecation RFC:
>>>> https://wiki.php.net/rfc/deprecations_php_8_4
>>>
>>> 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.
>>
>> That's the context/background here.  Whether that encourages you to vote for or
>> against that section I leave as an exercise for the reader.
>
> Well, I wonder how that is supposed to work.  Assuming the underscore
> would be used as wildcard in a class name context, that could only be
> done after using that character as class name is no longer allowed.  So
> that would have to wait for the next major PHP version (at least).
>
> Note that I'm not worried about no longer being able to use an
> underscore as class name, but rather that this introduces another
> inconsistency to our indentifiers.  Disallowing an underscore as
> function name is obviously off the table, thanks to gettext.
>
> Christoph

I think someone checked and found no examples of someone using _ as a class name, so the impact of
removing it and/or using it for something else would be nearly nil.  That may still push _ as a
wildcard out to a future version, but I leave that up to others.  As I said, I don't have
strong feelings either way.

--Larry Garfield


Thread (97 messages)

« previous php.internals (#124560) next »