Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124560
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-582-g5a02f8850-fm-20240719.002-g5a02f885
Precedence: bulk
MIME-Version: 1.0
Message-ID: <7d0cebed-023d-4490-ae65-0627bd9a4fe5@app.fastmail.com>
In-Reply-To: <49c17116-8f96-4429-ae56-0024a7981852@gmx.de>
References: 
 <USzt7tZZlO1DmAbSTLhD-bqa23FqZn0zk2aah8Ndxgk9c7RY5PefQ8MjbYPUYAzr2_m4Cf-5AI4PuNBTS84rim_FNS6RaT-cWSv714HEvvU=@gpb.moe>
 <CAJp_myW1cGAZT-183cKTEQus1G3KJiW2vHx6GtdYP78pZc1evQ@mail.gmail.com>
 <ffd507a4-7f8d-4e3d-a477-e59c96b582ba@app.fastmail.com>
 <49c17116-8f96-4429-ae56-0024a7981852@gmx.de>
Date: Tue, 23 Jul 2024 14:54:30 +0000
To: "php internals" <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

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=E2=80=AFPM Gina P. Banyard <internals@=
gpb.moe> 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 na=
me"
>>> 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 i=
n 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` alrea=
dy 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 ap=
proach in other languages.  We've indicated that we are open to making t=
hat an optional secondary vote in the pattern matching RFC if there's en=
ough 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 v=
ote 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 cl=
ass name, so the impact of removing it and/or using it for something els=
e would be nearly nil.  That may still push _ as a wildcard out to a fut=
ure version, but I leave that up to others.  As I said, I don't have str=
ong feelings either way.

--Larry Garfield