Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » [RFC] Reserve keywords in PHP 8 »

[RFC] Reserve keywords in PHP 8

php.internals

Ilija Tovilo

6 years ago
Hi internals I created a new RFC for reserving keywords we might need in PHP 8.x versions. https://wiki.php.net/rfc/reserve_keywords_in_php_8 Let me know if there's something you'd like to work on that will require a keyword and I will add it to the list. The keywords will most likely be voted on separately. Ilija

Kalle Sommer Nielsen

6 years ago
Hi Den lør. 13. jun. 2020 kl. 22.10 skrev Ilija Tovilo <tovilo.ilija@gmail.com>:
> > Hi internals > > I created a new RFC for reserving keywords we might need in PHP 8.x versions. > https://wiki.php.net/rfc/reserve_keywords_in_php_8 > > Let me know if there's something you'd like to work on that will > require a keyword and I will add it to the list. The keywords will > most likely be voted on separately.
I do not see a point in soft reserving something we don't even know if it will make it into 8.x. I mean sure you might work on some of them, but they should be voted on a case by case basis. We did future reserve somethings in the past for PHP6, e.g. the "b" string prefix and the "(binary)" cast (for the then non unicode strings). See: https://3v4l.org/nFJHb We stopped trying to future proof code by soft reserving after PHP6 turned out to be nothing and most of the features were ported to PHP5.3. I don't think we should go down that path again of soft reserving something before we can guarantee it will be implemented, something we cannot currently until it is voted in.
-- regards, Kalle Sommer Nielsen kalle@php.net

Matthew Brown

6 years ago
> I do not see a point in soft reserving something we don't even know if > it will make it into 8.x.
An enum implementation seems like something that almost certainly will make it into the language in the next 4 years, given PHP’s gradual adoption of features that already exist Hack (e.g. attributes, constructor property promotion). While there have been many attempts to emulate enums in the language, none have the simplicity nor ergonomics of actual native enum support.

Ilija Tovilo

6 years ago
Hi Kalle, hi Matthew
> We stopped trying to future proof code by soft > reserving after PHP6 turned out to be nothing and most of the features > were ported to PHP5.3.
I wanted to reduce resistance to the RFC I'm planning because of BC breaks in a minor version. For this reason I would personally prefer to have the BC break in a major version but I'm ok with either approach. It's worth noting that we did indeed register some keywords in PHP 7 before they were used: https://wiki.php.net/rfc/reserve_even_more_types_in_php_7
> An enum implementation seems like something that almost certainly > will make it into the language in the next 4 years, given PHP’s > gradual adoption of features that already exist Hack (e.g. attributes, > constructor property promotion).
Yes, this is my sentiment too. Ilija

Marco Pivetta

6 years ago
Hey Ilija, On Sat, Jun 13, 2020 at 9:10 PM Ilija Tovilo <tovilo.ilija@gmail.com> wrote:
> Hi internals > > I created a new RFC for reserving keywords we might need in PHP 8.x > versions. > https://wiki.php.net/rfc/reserve_keywords_in_php_8 > > Let me know if there's something you'd like to work on that will > require a keyword and I will add it to the list. The keywords will > most likely be voted on separately. >
This seems messy now, mostly because the `enum` symbol is very much in use in very stable packages: * https://packagist.org/packages/marc-mabe/php-enum/stats * https://packagist.org/packages/myclabs/php-enum/stats Greets, Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/

Ilija Tovilo

6 years ago
Hi Marco
>> I created a new RFC for reserving keywords we might need in PHP 8.x versions. >> https://wiki.php.net/rfc/reserve_keywords_in_php_8 > > This seems messy now, mostly because the `enum` symbol is very much in use in very stable packages: > > * https://packagist.org/packages/marc-mabe/php-enum/stats > * https://packagist.org/packages/myclabs/php-enum/stats
Hmm, I see your point. Although, myclabs/php-enum having the momentum it does, the situation might be worse for PHP 8.1. Ilija

Alex Dowad

6 years ago
Maybe it would be good to talk to the developers of that package? They might have some valuable input on how to design a built-in `enum` feature. It might also help them plan out a migration path. On Mon, Jun 15, 2020 at 11:18 AM Ilija Tovilo <tovilo.ilija@gmail.com> wrote:

Unnamed Person

6 years ago
On Mon, Jun 15, 2020 at 2:17 AM Marco Pivetta <ocramius@gmail.com> wrote:
> > Hey Ilija, > > On Sat, Jun 13, 2020 at 9:10 PM Ilija Tovilo <tovilo.ilija@gmail.com> wrote: > > > Hi internals > > > > I created a new RFC for reserving keywords we might need in PHP 8.x > > versions. > > https://wiki.php.net/rfc/reserve_keywords_in_php_8 > > > > Let me know if there's something you'd like to work on that will > > require a keyword and I will add it to the list. The keywords will > > most likely be voted on separately. > > > > This seems messy now, mostly because the `enum` symbol is very much in use > in very stable packages: > > * https://packagist.org/packages/marc-mabe/php-enum/stats > * https://packagist.org/packages/myclabs/php-enum/stats > > Greets, > > Marco Pivetta > > http://twitter.com/Ocramius > > http://ocramius.github.com/
How viable would be a compilation warning when a `T_STRING` is `enum`? I'm sure for the most part authors would much rather have enums in core than to maintain their own, though I haven't looked at implementations to see how "exotic" they are. If it's a warning then we can manage until it's implemented and the software can continue working but nobody will have to invest more time into it.