[RFC] Scalar Type Hinting With Casts (re-opening)

10 years ago by Theodore Brown — view source

unread

Since I am very much in favour of scalar type hints, I've updated the
patch to master and made some minor improvements, and I am re-opening
the RFC with the intent to try and get it into PHP 5.7.

First of all, this is my first reply on PHP Internals so I hope I am doing it right. :)

Thank you very much Andrea for reviving this RFC - I'm really looking forward to using
something like this in the next version of PHP to more easily define interfaces and
catch unintended errors in my code.

However, something I feel it is important to consider is not just how scalar type
annotations fit into the history of PHP, but how they fit with the way type annotations
are currently used and where the language is going in the future.

A recurring comment I've heard in the discussion for this RFC is that strict type hints
aren't "the PHP way." However, current type hints for classes, arrays, and callables
work exactly in this way - they do not allow nulls, no casting is performed, and an
invalid type results in a fatal error. If scalar annotations are introduced, many PHP
developers (myself included) would naturally expect them to behave in the same way.

Another concern I have is in regard to the future. I'm looking forward to the
possibility of specifying nullable types in a future version of PHP (see Levi Morrison's "Declaring Nullable Types" RFC: http://wiki.php.net/rfc/nullable_typehints). If the
nullable types RFC is accepted, it would be highly disconcerting if scalar type
annotations allowed null values regardless of whether a nullable marker is specified.

I don't think that optional strict type annotations will take away from PHP's dynamic
nature - they will instead be a valuable feature used in places where it is necessary
to strictly validate a parameter's type - this is especially important to ensuring
stability and accuracy in the large PHP applications it is my job to maintain.

The RFC has already been updated to make boolean type annotations strict. Doesn't it
make sense to treat the other scalar types in the same way? Perhaps a future RFC could
propose a second (also optional) syntax to specify type annotations which perform casts.
However, only having cast-based annotations for scalar types would be a mistake, IMHO.

--

Theodore Brown

A PHP developer interested in the language's future

10 years ago by Simon Schick — view source

unread

Since I am very much in favour of scalar type hints, I've updated the
patch to master and made some minor improvements, and I am re-opening
the RFC with the intent to try and get it into PHP 5.7.

First of all, this is my first reply on PHP Internals so I hope I am doing it right. :)

Thank you very much Andrea for reviving this RFC - I'm really looking forward to using
something like this in the next version of PHP to more easily define interfaces and
catch unintended errors in my code.

However, something I feel it is important to consider is not just how scalar type
annotations fit into the history of PHP, but how they fit with the way type annotations
are currently used and where the language is going in the future.

A recurring comment I've heard in the discussion for this RFC is that strict type hints
aren't "the PHP way." However, current type hints for classes, arrays, and callables
work exactly in this way - they do not allow nulls, no casting is performed, and an
invalid type results in a fatal error. If scalar annotations are introduced, many PHP
developers (myself included) would naturally expect them to behave in the same way.

Another concern I have is in regard to the future. I'm looking forward to the
possibility of specifying nullable types in a future version of PHP (see Levi Morrison's "Declaring Nullable Types" RFC: http://wiki.php.net/rfc/nullable_typehints). If the
nullable types RFC is accepted, it would be highly disconcerting if scalar type
annotations allowed null values regardless of whether a nullable marker is specified.

I don't think that optional strict type annotations will take away from PHP's dynamic
nature - they will instead be a valuable feature used in places where it is necessary
to strictly validate a parameter's type - this is especially important to ensuring
stability and accuracy in the large PHP applications it is my job to maintain.

The RFC has already been updated to make boolean type annotations strict. Doesn't it
make sense to treat the other scalar types in the same way? Perhaps a future RFC could
propose a second (also optional) syntax to specify type annotations which perform casts.
However, only having cast-based annotations for scalar types would be a mistake, IMHO.

--

Theodore Brown

A PHP developer interested in the language's future

--

Hi, all

First of all, thanks for all your time, you put into this thread! I
really am looking forward for a way, all can live with, because this
topic has followed the PHP community since the release of PHP 5.1,
since the introduction of type hinting for arrays
(http://php.net/manual/en/language.oop5.typehinting.php).

On an archive for this mailinglist I found threads that are going back
to 2005 (http://marc.info/?l=php-internals&m=112397232722668&w=2) -
Here's a list of all messages found:
http://marc.info/?l=php-internals&s=type+hinting&q=b

I've been one of the most active contributors to a thread back in 2012

not the one giving most productive feedback, but the one giving the
most feedback ... (I later saw a statistic of who posted the most
mails to the mailinglist within the months of discussion)

What I see, we're again stuck with mainly three different opinions, as
Paul Biggar pointed out in his post - and he tried to find a solution
back then. I would suggest that anyone should read this mail - if you
want, read the thread - I haven't had the time for now..:
http://marc.info/?l=php-internals&m=124653792412529&w=2

In every round we took this topic, there have been new RFCs added ...
I don't know if there will be a solution, and my personal favorite is
the way, proposed in this RFC here. No casting for the values, just
more a validation - a lossy validation.

The main reason for this proposal is, that mostly every input to your
application will be a string. If it now is a file, a value from the
database, the GET and POST parameters, a CURL response - nearly
anything. I don't think it makes sense to first cast them before you
can use them.

I agree, that it feels wrong to have a method, accepting
(string)"123abc" and casting it to (int)123 for internal usage, but it
also feels wrong to not let the input (string)"123" pass as a
parameter to a method accepting integer. This would lead us to casting
(f.e. substr("string", (int)$var) ), what again would be like accept
anything ($var = "abc").

I also saw some complaining about that older code may will not work
when introducing something here. As of what I think, this should be
implemented as an extension to the language as it is now. Old code
should be able to run as it is. You may will get a problem when your
old code is using a library, that you want to update and the library
is using the new syntax ;)

Thanks for reading.

Bye
Simon

10 years ago by Andrea Faulds — view source

unread

Another concern I have is in regard to the future. I'm looking forward to the
possibility of specifying nullable types in a future version of PHP (see Levi Morrison's "Declaring Nullable Types" RFC: http://wiki.php.net/rfc/nullable_typehints). If the
nullable types RFC is accepted, it would be highly disconcerting if scalar type
annotations allowed null values regardless of whether a nullable marker is specified.

The current proposed behaviour could be changed. At the moment, if a scalar type hint is nullable, then it won’t cast NULL if it’s passed that value, but if it’s not nullable, then it will cast it.

Considering how this tends to only allow lossless casts, though, it might be worth reconsidering this and just disallowing NULL altogether. It’s worth pointing out that NULL is usually an error value, and you might get it from using an uninitialised variable or calling an internal function with bad parameters.

--
Andrea Faulds
http://ajf.me/

10 years ago by Andrea Faulds — view source

unread

Another concern I have is in regard to the future. I'm looking forward to the
possibility of specifying nullable types in a future version of PHP (see Levi Morrison's "Declaring Nullable Types" RFC: http://wiki.php.net/rfc/nullable_typehints). If the
nullable types RFC is accepted, it would be highly disconcerting if scalar type
annotations allowed null values regardless of whether a nullable marker is specified.

The current proposed behaviour could be changed. At the moment, if a scalar type hint is nullable, then it won’t cast NULL if it’s passed that value, but if it’s not nullable, then it will cast it.

Considering how this tends to only allow lossless casts, though, it might be worth reconsidering this and just disallowing NULL altogether. It’s worth pointing out that NULL is usually an error value, and you might get it from using an uninitialised variable or calling an internal function with bad parameters.

I’ve updated the RFC and patch to make int, string and double nullability work like the other types (bool already did). If the default value isn’t NULL, NULL isn’t accepted and you’ll get E_RECOVERABLE_ERROR. If the default value is NULL, NULL is accepted and will not be casted.

This will likely lead to less bugs as `NULL` is a common error value, and it also makes the scalar type hints more consistent with the others.

Andrea Faulds
http://ajf.me/

10 years ago by Andrea Faulds — view source

unread

double

Did I just say double? I meant float, of course. :)

The patch actually warns you if you try to do this now:

function foo(double $foo) {}
foo(1.0);

If you use one of the non-existent aliases (double), and pass the type that alias is supposed to hint for (a float), the error message notes you might be looking for the actual type hint (float).

The same for integer and boolean (only int and bool, respectively, are permitted).

Andrea Faulds
http://ajf.me/

10 years ago by Theodore Brown — view source

unread

Another concern I have is in regard to the future. I'm looking
forward to the possibility of specifying nullable types in a
future version of PHP (see Levi Morrison's "Declaring Nullable
Types" RFC: http://wiki.php.net/rfc/nullable_typehints). If the
nullable types RFC is accepted, it would be highly disconcerting
if scalar type annotations allowed null values regardless of
whether a nullable marker is specified.

The current proposed behaviour could be changed. At the moment, if
a scalar type hint is nullable, then it won’t cast NULL if it’s
passed that value, but if it’s not nullable, then it will cast it.

Considering how this tends to only allow lossless casts, though, it
might be worth reconsidering this and just disallowing NULL > altogether. It’s worth pointing out that NULL is usually an error
value, and you might get it from using an uninitialised variable or
calling an internal function with bad parameters.

The same thing applies to boolean values. FALSE is frequently returned
from internal functions when an error occurs, and allowing it to be
passed to a function expecting a different scalar type could mask errors.

After reading Simon's response I do feel it would be a reasonable
compromise to allow strings to be cast to int/float (and vice versa) as
long as no data loss occurs (following the current rules in the RFC).
If the RFC is updated to disallow NULL altogether and also disallow
boolean values for other scalar types I would be 100% supportive.

--

Theodore Brown

A PHP developer interested in the future of the language

10 years ago by Theodore Brown — view source

unread

I’ve updated the RFC and patch to make int, string and double nullability work like the other types (bool already did). If the default value isn’t NULL, NULL isn’t accepted and you’ll get E_RECOVERABLE_ERROR. If the default value is NULL, NULL is accepted and will not be casted.

This will likely lead to less bugs as NULL is a common error value, and it also makes the scalar type hints more consistent with the others.

Thank you very much for making this change. It goes a long way towards making scalar type annotations more useful to me as a userland developer. Also, I really like the new "numeric" type hint.

The one remaining issue I have with this proposal is that boolean values are currently accepted for every other scalar type except array. As with NULL, FALSE is a common error value, and allowing booleans to be passed to a function expecting a string or numeric value could easily mask errors and lead to hard-to-debug issues in a program. Just as a string cannot be passed to a function expecting a boolean, a boolean should not be passed to a function expecting a string, etc.

Thanks for all you do for the community.

--

Theodore Brown

A PHP developer interested in the future of the language

10 years ago by Andrea Faulds — view source

unread

The one remaining issue I have with this proposal is that boolean values are currently accepted for every other scalar type except array. As with NULL, FALSE is a common error value, and allowing booleans to be passed to a function expecting a string or numeric value could easily mask errors and lead to hard-to-debug issues in a program. Just as a string cannot be passed to a function expecting a boolean, a boolean should not be passed to a function expecting a string, etc.

After consulting with Anthony about this, the RFC and patch have been updated to disallow booleans for int, float, numeric and string type hints. The conversions table now looks like this:

https://wiki.php.net/rfc/scalar_type_hinting_with_cast#conversion_rules

Andrea Faulds
http://ajf.me/

10 years ago by Stas Malyshev — view source

unread

Hi!

After consulting with Anthony about this, the RFC and patch have been
updated to disallow booleans for int, float, numeric and string type
hints. The conversions table now looks like this:

This makes very little sense, 0 means the same as false is in many
contexts in PHP and also in many languages. Having random arcane rules
would only make the users curse us every time they get tripped by them.
I call everybody to vote against this RFC - it's better not to have such
thing at all then to promise our users improvement only for them to
discover this improvement is fraught with inconsistent arbitrary rules
that do not match what the rest of the language is doing - even within
the same context of the function call. I can see no uniting principle
behind this table, which is randomly strict and randomly non-strict
without connection to the rest of PHP. I do not think it is the right
thing to have such thing in the language, even if it would help
somebody's particular use-case.

Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/

10 years ago by Andrea Faulds — view source

unread

This makes very little sense, 0 means the same as false is in many
contexts in PHP and also in many languages.

It also means very different things in some places, particularly return values. strpos returning 0 is most definitely not the same thing as strpos returning FALSE. That’s a big reason why FALSE and TRUE aren’t accepted for int type hints: bools are common error values.

Having random arcane rules
would only make the users curse us every time they get tripped by them.

The rules are not random nor arcane.

I call everybody to vote against this RFC - it's better not to have such
thing at all then to promise our users improvement only for them to
discover this improvement is fraught with inconsistent arbitrary rules

How are they inconsistent and arbitrary? These rules haven’t been picked at random from a hat, they’ve come from a process of careful thought. Casting an integer to a string and vice-versa makes sense and is a common operation ($_GET[‘id’]), while casting a NULL or FALSE to a string doesn’t really make sense (when do you need to do this?), and is unlikely to happen unless something’s gone wrong.

that do not match what the rest of the language is doing

That is true, but it would be possible to change zpp later.

even within
the same context of the function call. I can see no uniting principle
behind this table, which is randomly strict and randomly non-strict
without connection to the rest of PHP. I do not think it is the right
thing to have such thing in the language, even if it would help
somebody's particular use-case.

The point of this RFC is to strike a compromise that is generally useful rather than helping one specific use case (strict hints) or another (casts).

--
Andrea Faulds
http://ajf.me/

10 years ago by Stas Malyshev — view source

unread

Hi!

The point of this RFC is to strike a compromise that is generally
useful rather than helping one specific use case (strict hints) or
another (casts).

What you call "compromise" is the inconsistency - it's not strict
typing, it's not weak typing, it's half that and half this without any
apparent principle uniting them but arbitrarily constructed table, to
which anybody using it would have to constantly refer to figure out why
their code is breaking. I'm sure you carefully thought about each and
every cell in that table, but that does not make it any better for the
user - in fact, it makes it worse, since absent the obvious uniting
principle it means each time the user encounters it it has to
reconstruct the long and laborious thought process anew or just learn
the whole table by hard. It is not a good design. Good design is where
you can predict what the language would do without remembering a bunch
of exceptions that are just so.

Even worse, it does not match what other functions are doing and what
other type conversions are doing. It's like a "compromise" of cutting
the baby in half - much worse than any of the original proposals. Only
in the case of Solomon it was a trick, you on the other side propose it
as a serious and preferable solution. This kind of "compromise" is not a
positive thing, but a negative.

Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/

10 years ago by Zeev Suraski — view source

unread

Hi!

The point of this RFC is to strike a compromise that is generally
useful rather than helping one specific use case (strict hints) or
another (casts).

What you call "compromise" is the inconsistency - it's not strict
typing, it's not weak typing, it's half that and half this without any
apparent principle uniting them but arbitrarily constructed table, to
which anybody using it would have to constantly refer to figure out why
their code is breaking.

Well put.

Zeev

10 years ago by Christoph Becker — view source

unread

Andrea Faulds wrote:

that do not match what the rest of the language is doing

That is true, but it would be possible to change zpp later.

IMHO it might be a good idea to have a respective RFC wrt. ZPP first.
It might be possible and sensible to change ZPP for PHP NEXT. If that
RFC would pass, it makes sense to use these rules for the type hints,
what might be already introduced in PHP 5.7 (if this version will be
released).

--
Christoph M. Becker

[RFC] Scalar Type Hinting With Casts (re-opening)

This will likely lead to less bugs as NULL is a common error value, and it also makes the scalar type hints more consistent with the others.

The same for integer and boolean (only int and bool, respectively, are permitted).

https://wiki.php.net/rfc/scalar_type_hinting_with_cast#conversion_rules

This will likely lead to less bugs as `NULL` is a common error value, and it also makes the scalar type hints more consistent with the others.