[RFC] Reserving More Types in PHP 7 View as Markdown

Hi,

Agree on 'double' though ... if we want to discourage its usage, we
might even think of deprecating it.

While deprecating it might be a good course of action, it is out of
scope of this RFC. I personally think that reserving it is a good way
to discourage its use: simply reserve it and then don't use it for
anything. If we decide not to use the aliases if we have scalar types
and the aliases are reserved this would prevent users from making
custom types from the aliases. In my opinion this a Good Thing.

Well, I meant to deprecate is_double(), is_real() and the
corresponding explicit casts. I might be missing other places when
they are used, not sure, but the point would be to stop using these
names for scalar types at all, so that everybody can freely use them
for class/trait/interface names ... I don't think anybody would do
that only for pseudo-scalar hinting objects.

So, while yes - that's outside of this RFC's scope, reserving them as
keywords would be the opposite of what I had in mind.

Cheers,
Andrey.

Add 'resource', 'object', 'scalar', 'mixed', 'numeric'

If someone wants to reserve these I will leave them up to another RFC,
as I suspect they are more controversial than what I have proposed.

Done https://wiki.php.net/rfc/reserve_even_more_types_in_php_7

-Sara

Hi,

Hi Andrey,

I think the question of reserving 'resource' or not is not the main one.

The question of having to reserve keywords is much more fundamental and needs to be addressed first. I expect it to be clear for everyone that, as long as we share the same naming space between class/interface/trait names and type hinting keywords, each addition of a new keyword will be a real problem. So, we may reserve keywords in advance but it cannot be more than a workaround. If we don't address the issue now, we'll end up with weird names for type hints, just because appropriate ones are too appropriate and potentially taken for existing or future classes, without any way to evaluate the potential BC break, let alone the potential introduction of a third naming space with a future 'typedef' feature ;). We see the case today with 'resource' but that's just the beginning. What about 'mixed', 'scalar', or others I don't imagine yet ? The race to reserving keywords is lost in advance.

Another point is that, thinking the reverse way, developers can legitimately ask why they cannot choose 'resource' as a class name, when the reason for this is a design mistake made when the 'array' type hint was introduced, or even before, when class hints were introduced without thinking the mechanism would be necessarily be extended.

Just a detail: I respectfully suggest anyone not to waste time to explain that the problem is solved by using lowercase-only keywords, at least not to me ;)

So, we need to propose a migration path towards a cleaner syntax. The STH RFC we are writing proposes one, keeping it as smooth as possible because the feature is heavily used.

Back to the particular case of 'resource': As the future of resources may be to be converted to objects while keeping the same API, the STH RFC will propose to define the 'resource' type hint as accepting 'IS_RESOURCE|IS_OBJECT', without conversion. Then the user who received it can distinguish with is_resource/is_object() if needed.

So, 'resource' and 'resource|object' will be synonyms, while more precise users can use something like 'resource|object(GMP)'. All of these syntaxes will provide full BC when switching from resource to OO.

Thought ?

Sorry François, but I really didn't intend to go further into that topic.

If Levi decides to add it as a second, optional vote - it's his
proposal and that's fine with me. I only expressed my opinon about
your suggestion to also reserve 'resource', because I don't have
voting karma and RFC discussion is my only way of influencing
decisions.

Cheers,
Andrey.