Soft-reserve "void" class name

+1

Hi internals!

For PHP 7 we soft-reserved a number of class names [1] like "numeric", so
that we have the ability to introduce them as typehints in a 7.x release.
"Soft" here means that we only document these names as being reserved and
don't throw an error when they're used.

I'd like to add "void" to this list, so we have the option to introduce a
void return type in PHP 7.x. I've seen some disagreement as to whether this
should be called "void" or "null" - this discussion should be held when an
RFC comes up, however we need to keep both options open until then.
(Currently only "null" is reserved.)

If people think that this requires a vote, I'll open one.

I'm OK with it.

Julien

Le Tue, 19 May 2015 17:28:34 +0200, Nikita Popov nikita.ppv@gmail.com a
écrit:

Hi internals!

For PHP 7 we soft-reserved a number of class names [1] like "numeric", so
that we have the ability to introduce them as typehints in a 7.x release.
"Soft" here means that we only document these names as being reserved and
don't throw an error when they're used.

I'd like to add "void" to this list, so we have the option to introduce a
void return type in PHP 7.x. I've seen some disagreement as to whether
this
should be called "void" or "null" - this discussion should be held when
an
RFC comes up, however we need to keep both options open until then.
(Currently only "null" is reserved.)

If people think that this requires a vote, I'll open one.

Thanks,
Nikita

[1] https://wiki.php.net/rfc/reserve_even_more_types_in_php_7

Hi,

While I'm impatient to see "void" in the engine, we should follow the
process rules. This is something that have to go through an RFC. If we
implement it, even a soft reservation, without following the process, it
opens the door to all kind of dangerous situations.

So while I like your idea, it shouldn't be implemented before 7.1

Regards.

Hi,

De: "Nikita Popov" nikita.ppv@gmail.com

For PHP 7 we soft-reserved a number of class names [1] like "numeric", so
that we have the ability to introduce them as typehints in a 7.x release.
"Soft" here means that we only document these names as being reserved and
don't throw an error when they're used.

I'd like to add "void" to this list, so we have the option to introduce a
void return type in PHP 7.x. I've seen some disagreement as to whether this
should be called "void" or "null" - this discussion should be held when an
RFC comes up, however we need to keep both options open until then.
(Currently only "null" is reserved.)

May I repeat my arguments to have this reservations enforced by a warning message ? 'Soft' reservation
is easier but it is not enough. If we give a special meaning to one of these names in a 7.x release,
we will introduce a BC break, whatever the documentation states, because that's the definition of a BC
break : software that works fine in 7.0 and does not work the same in 7.x. Do we want to guarantee BC on
minor versions ? If we don't enforce a check on reserved class names, IMO, we can't. Once again, this is
a short-term half-baked solution we'll pay later.

PS: If you're OK, I am ready to implement the check.

Regards

François

Hi!

I'd like to add "void" to this list, so we have the option to introduce a
void return type in PHP 7.x. I've seen some disagreement as to whether this

I think this type makes no sense in PHP, but I don't object to having
note in the docs for people not to name their classes "void" (not that
there's any reason to do it anyway...). I strongly object to introducing
any changes in the code though - warnings, etc.

--
Stas Malyshev
smalyshev@gmail.com