[RFC] Additional soft-reservations for PHP 7

Hi internals!

In a previous thread on the topic 1 I promised to create an RFC for the
soft-reservation of 'void', similar to a bunch of other reservations we
have done for PHP 7. The RFC also includes 'enum' as an additional
independent proposal, as I think this will likely be needed in 7.x. If you
have further suggestions for names or keywords that we are likely to need,
please point them out.

https://wiki.php.net/rfc/additional_soft_reservations_for_php7

Thanks,
Nikita

Yea, this is smart to get this going. I think it makes a lot of sense. I'd
love to see "struct" added to this list, so we could potentially add a
value object structure of some sort down the road.

As far as "prior art", you can see that there's already some interest in
this area:

• https://twitter.com/auroraeosrose/status/616321058904350720
• https://gist.github.com/auroraeosrose/2036d1d675a4bd254450
• https://gist.github.com/Antnee/237334e1eb937892ad7a

Anyway, yea. Makes sense to me. ?

So there are two questions to answer here:

a) How likely is it that this will be implemented in the near future? I've
added "enum" to the list, because there is already an existing proposal,
which I personally consider relatively likely to pass. Structs are as-yet a
vague concept and may be implemented in very different ways. As far as I
see the only fundamental difference between a "struct" and a "class" per
the above definition is that you can't create dynamic properties on it -
which is something that can be solved from a different angle as well
(declare strict mode).

b) Do we really need a keyword to implement this feature? For example,
instead of "struct Foo {}" we could use the syntax "struct class Foo {}",
in which case the new "keyword" would be "struct class" and we do not cause
BC issues. Note that this also applies to "enum" where we could use "enum
class Foo {}" instead. This syntax has precedent in C++11. Thinking about
this now, this might be a better option, because there's a lot of code
using "enum" in name segments 1 (it's pretty much the natural choice for
userland enum implementations...) and introducing this keyword might result
in a non-trivial amount of breakage (cc Levi). "struct" looks less
problematic 2.

Nikita