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
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_8Let 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
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.
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
Hey Ilija,
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_8Let 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
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_8This seems messy now, mostly because the
enumsymbol is very much in use in very stable packages:
Hmm, I see your point. Although, myclabs/php-enum having the momentum
it does, the situation might be worse for PHP 8.1.
Ilija
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.
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_8This seems messy now, mostly because the
enumsymbol is very much in use in very stable packages:Hmm, I see your point. Although, myclabs/php-enum having the momentum
it does, the situation might be worse for PHP 8.1.Ilija
Hey Ilija,
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_8Let 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
enumsymbol 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
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.