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

It is very direct specification of
either strict parameter typing or coercive parameter typing. I don't
think using confusing terminology helps anything here. I think it was a
mistake to introduce this term from the start and we should stop
propagating it.

It does come across as as an attempt to hide the 'strict parameter
typing' which is something that is very much less attractive. If I
wanted that then I'd simply switch back to C/C++ direct which is perhaps
where we are now heading anyway with the increasing use of pre-compiled
application code?

One of the reasons I persist with PHP is the fact that many of my users
can adjust the odd PHP file correcting sequence or modifying text
without having to learn the intricacies of formal programming. It's
adding all these complex layers that is taking PHP away from it's more
novice friendly base ... If you want a formal programming language then
just use one?

--
Lester Caine - G8HFL

Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

I have one request: could we please stop calling it "hinting"?
The dictionary says (http://www.thefreedictionary.com/hint) that
the word "hint" means:

1. A slight indication or intimation: wanted to avoid any hint of scandal.

a. A brief or indirect suggestion; a tip: stock-trading hints.
b. A statement conveying information in an indirect fashion; a clue:
Give me a hint about the big news.

3. A barely perceptible amount: just a hint of color.

What we have in PHP and what is being proposed it not a "slight
indication", not "suggestion" and not "conveying information in indirect
fashion" (what Python does in PEP-3107 could be called that way, but
it's not what is proposed here). It is very direct specification of
either strict parameter typing or coercive parameter typing. I don't
think using confusing terminology helps anything here. I think it was a
mistake to introduce this term from the start and we should stop
propagating it.

I agree that “type hinting” is a bad name for it. Perhaps “optional typing” would be better. It conveys that these specifiers are completely optional, and that there is a system of typing, but it doesn’t say anything about its strictness.

Regardless, this RFC will stick with the current terminology, but changing the terminology would be quite simple, you could just update the manual and possibly change some of the internal names.

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

I have one request: could we please stop calling it "hinting"?

I've always thought the current "type hinting" should be called "type
assertion", since passing the wrong data type is detected only at
runtime, and causes an error in much the same way as if you wrote
assert($param instanceof HintedClass).

What this RFC proposes is more like "type validation" - detecting that
the given input can be safely coerced to the given type, and performing
the coercion in the process. As Andrea points, out, it's similar to what
Nikita called[1] "strict weak type hinting", but with the added step of
performing the cast, which is really just a convenience, since if you've
asked for a value to be validated as an int, you're presumably about to
use it as one.

[1]
http://nikic.github.io/2012/03/06/Scalar-type-hinting-is-harder-than-you-think.html

--
Rowan Collins
[IMSoP]

Am 13.07.2014 07:22, schrieb Stas Malyshev:

I think it was a mistake to introduce this term from the start and
we should stop propagating it.

What would be a better term? Optional strict typing in function and
method signatures?

Hi,

Would it possible to control the implicit casting through a PHP variable
? (or perhaps modify E_STRICT to display a warning if this kind of
implicit cast is done ?)
I mean specifying explicitly a type is often useful to make sure the
proper type is passed to the function, and there's no bug in the calling
func.

e.g. safety check like

function foo($bar) {
if (!is_int($bar)) {
throw new Exception('Invalid parameter type');
}
}

will not be "equivalent" to

function foo(int $bar) {

}

and there will be no way to have an equivalent behaviour once "type
hinting" is used !

Thanks,
Jocelyn

Le 13/07/2014 14:09, Nikita Popov a écrit :

Good evening,

PHP’s type hinting system is rather incomplete as it does not support
scalars, only arrays, callables and objects. In 2012, Anthony Ferrara
created an RFC which proposed type hinting for scalar types (int, float,
bool, string and resource) with casting, with behaviour nearly the same as
that of zend_parse_parameters. Sadly, he later left PHP internals and
withdrew his RFCs.

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. The patch is mostly
there. It needs some more tests and there are some edge cases I need to
deal with, but it otherwise works, and I expect I can finish fixing it up
very soon.

The RFC is here: https://wiki.php.net/rfc/scalar_type_hinting_with_cast

A pull request is here: https://github.com/php/php-src/pull/717

I’m hoping I can get this into PHP 5.7. I think scalar type hinting would
be a valuable addition to PHP’s existing type hinting system.

Thanks!

I think the approach described in this proposal is the best way to
implement scalar typehinting, as it allows typical loosely-typed usage
patterns, while still providing type guarantees within the function.

I haven't yet closely reviewed the details of what is and isn't allowed,
but one things I would strongly recommend against is introducing any
"accept but throw a notice" cases. Either a value is allowed or it isn't.
"12foo" to an int/float argument should throw a recoverable fatal error,
like everything else. (I'd change that in zpp as well, but that's a
different discussion).

The question of passing floats like 12.5 to an int param is somewhat
tricky. One could argue that it's possible to end up with floats like
12.0000000001, which are nearly integers but not quite there, and a user
might expect them to behave the same as the integer 12. On the other hand
one can also argue that it's easy to end up with the inverse, namely
11.999999999999. In this case the end user might also expect it to be
treated as integer 12, however an integer cast will truncate it to 11.

The truncation behavior of the float to int cast is why I tend towards the
behavior the RFC currently proposes (forbid non-integral floats): It is
rather unlikely that truncation is what was intended, as such an explicit
rounding call is necessary anyways.

Nikita

I haven't yet closely reviewed the details of what is and isn't allowed,
but one things I would strongly recommend against is introducing any
"accept but throw a notice" cases. Either a value is allowed or it isn't.
"12foo" to an int/float argument should throw a recoverable fatal error,
like everything else. (I'd change that in zpp as well, but that's a
different discussion).

I’ve changed this case in the RFC and my patch. Previously, “12foo” would just throw an E_NOTICE, but now it is not accepted:

Integer hints:

function foo(int $a) {
var_dump($a);
}
foo(1); // int(1)
foo("1"); // int(1)
foo(1.0); // int(1)
foo("1a"); // E_RECOVERABLE_ERROR
foo("a"); // E_RECOVERABLE_ERROR
foo(999999999999999999999999999999999999); // E_RECOVERABLE_ERROR (since it's not exactly representable by an int)
foo(1.5); // E_RECOVERABLE_ERROR

Float hints:

function foo(float $a) {
var_dump($a);
}
foo(1); // float(1)
foo("1"); // float(1)
foo(1.0); // float(1)
foo("1a"); // E_RECOVERABLE_ERROR
foo("a"); // E_RECOVERABLE_ERROR
foo(1.5); // float(1.5)

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

I haven't yet closely reviewed the details of what is and isn't allowed,
but one
things I would strongly recommend against is introducing any "accept but
throw a notice" cases. Either a value is allowed or it isn't.
"12foo" to an int/float argument should throw a recoverable fatal error,
like
everything else. (I'd change that in zpp as well, but that's a different
discussion).

The use case of converting string based values into integers and floating
point numbers is a very common one, given anything that comes into PHP as
input is a string. In terms of productivity, it's much easier for me to
stick an 'int' type hint (or whatever we call it) on a piece of $_GET value
that I know needs to be an integer, than it is for me to now surround it in
a try/catch block and protect against a user or a wannabe hacker sending in
'123abc' in there. In such a case treating this as 123 (int) makes perfect
sense, with the erroneous input silently converted to something sane the
code can live with. A key advantage of these casting type hints is saving
the need to write lengthy and somewhat obscure pieces of code that just
validate inputs. If we force developers to surround them with try/catch
blocks, we lose at least half of the value here IMHO.

I therefore think conversion from string to any of the basic types should
never result in an exception even if information is lost; And it does make

The question of passing floats like 12.5 to an int param is somewhat
tricky.
One could argue that it's possible to end up with floats like
12.0000000001,
which are nearly integers but not quite there, and a user might expect
them
to behave the same as the integer 12. On the other hand one can also argue
that it's easy to end up with the inverse, namely 11.999999999999. In this
case the end user might also expect it to be treated as integer 12,
however an
integer cast will truncate it to 11.

The truncation behavior of the float to int cast is why I tend towards the
behavior the RFC currently proposes (forbid non-integral floats): It is
rather
unlikely that truncation is what was intended, as such an explicit
rounding call
is necessary anyways.

I'm undecided on this one too.

Zeev

First of all thanks for this proposal. In general I’m hugely in favour of this approach.

One thing however seems like a rather bad idea, and that is exposing the type of resource in this way. Resources are not compatible between each other, making such a hint not very useable. If people start adding this hint to their methods it will also make it much harder to change resources into objects (like it has been done for gmp and I have a pull request for hash)

Those are good points. Is there any sane way to hint for them, then?

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

One of the issues with the RFC as it stands is how to handle bool casting. While int, float and string only allow lossless casting (with the exception of objects, but we can’t really do anything about that), bool’s behaviour at the moment is quite different. I don’t think it makes sense so I won’t discuss the current behaviour, only possible new ones.

One option is simply to forget about being lossless and make the bool type hint accept any value, meaning any truthy value or any falsey value would yield what is expected without error. This would ensure that if some stupid programmer (like myself ;) has passed in a non-boolean truthy/falsey value to your function, it’ll be handled correctly. It would mean all your bit hacks ($foo & FLAG etc.) would work, anything you got from $_GET (e.g. ?foobar=1). However, this is unlikely to catch bugs in code, because literally any PHP value would work. For that reason, I’m not sure this is the way forward.

I don’t think that "scalar casts” should do any additional error-catching. they target a very different usecase.
It shouldn’t guarantee correctness of the whole program. It should guarantee that variable types are fixed inside of function.

In my opinion, this patch should act 100% similar to zpp.
And if, at some later point zpp-behaviour changes similar change should happen to userland "scalar casts"

Some people talk about inconsistency, which is introduced by reusing same syntax for "strict parameter types" and "scalar parameter casts”. There’s some truth there.
Let’s use different syntax.

This might work:

function foo((int) $a)
{
    var_dump($a);
}

I would read it as declaration-level casting

--
Alexey Zakhlestin
CTO at Grids.by/you
https://github.com/indeyets
PGP key: http://indeyets.ru/alexey.zakhlestin.pgp.asc

Hello again,

One of the issues with the RFC as it stands is how to handle bool casting. While int, float and string only allow lossless casting (with the exception of objects, but we can’t really do anything about that), bool’s behaviour at the moment is quite different. I don’t think it makes sense so I won’t discuss the current behaviour, only possible new ones.

One option is simply to forget about being lossless and make the bool type hint accept any value, meaning any truthy value or any falsey value would yield what is expected without error. This would ensure that if some stupid programmer (like myself ;) has passed in a non-boolean truthy/falsey value to your function, it’ll be handled correctly. It would mean all your bit hacks ($foo & FLAG etc.) would work, anything you got from $_GET (e.g. ?foobar=1). However, this is unlikely to catch bugs in code, because literally any PHP value would work. For that reason, I’m not sure this is the way forward.

Another option is go completely strict and allow only boolean values, failing everything else. This would be unlike the int, float and string hints, which are flexible and cast, but would be more helpful for catching bugs. However, not casting at all isn’t very “PHP-like”, and forcing people to manually cast with (bool) might not be ideal. If we were to go for this one, I might also accept objects casting to bool (which the default handler does), because I don’t want to stop extension developers from making bool-like objects if they so please.

The final option I’m thinking about is a limited set of values. TRUE, FALSE and NULL would be accepted, along with the integer and float values 1 and 0 (which are the int/float TRUE and FALSE cast to, respectively), ‘1’ and the empty string (which are the string values TRUE and FALSE cast to), and ‘0’ (which (string)(int)FALSE would give you), along with objects casting to boolean. It’s not a perfect solution, but I currently feel that this is the most sensible option bar going for full strictness.

I’m not really decided, however. Every time I try to think about this, I usually end up going in circles. Anthony doesn’t seem to be decided either. Hence I’m putting this up for discussion.

What are your thoughts?

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

I've already said this in IRC but summing up for the benefit of everyone else:

1. We already have a place where there is an implicit boolean cast,
   namely if ($var). Personally I would find it somewhat
   counter-intuitive if a parameter declared as bool didn't behave the
   same way.

2. A common-ish use case here would be:

   function foo(bool $bool) {}
   foo($flags & A_FLAG);

The intent of the expression $flags & A_FLAG is obvious to the reader
as fetching a boolean, but the result will often be an integer that is
neither 1 nor 0. This cannot be handled by foo((bool)$flags & A_FLAG);
because of precedence, foo((bool)($flags & A_FLAG)); is messy. Andrea
suggested foo($flags & A_FLAG != 0); which is better but still a
little messy.

Personally I would rather just accept data loss and stay consistent
with the rest of the language (i.e. condition evaluation), but I do
understand the PoV of those resistant to it.

Hello again,

One of the issues with the RFC as it stands is how to handle bool casting. While int, float and string only allow lossless casting (with the exception of objects, but we can’t really do anything about that), bool’s behaviour at the moment is quite different. I don’t think it makes sense so I won’t discuss the current behaviour, only possible new ones.

One option is simply to forget about being lossless and make the bool type hint accept any value, meaning any truthy value or any falsey value would yield what is expected without error. This would ensure that if some stupid programmer (like myself ;) has passed in a non-boolean truthy/falsey value to your function, it’ll be handled correctly. It would mean all your bit hacks ($foo & FLAG etc.) would work, anything you got from $_GET (e.g. ?foobar=1). However, this is unlikely to catch bugs in code, because literally any PHP value would work. For that reason, I’m not sure this is the way forward.

Another option is go completely strict and allow only boolean values, failing everything else. This would be unlike the int, float and string hints, which are flexible and cast, but would be more helpful for catching bugs. However, not casting at all isn’t very “PHP-like”, and forcing people to manually cast with (bool) might not be ideal. If we were to go for this one, I might also accept objects casting to bool (which the default handler does), because I don’t want to stop extension developers from making bool-like objects if they so please.

The final option I’m thinking about is a limited set of values. TRUE, FALSE and NULL would be accepted, along with the integer and float values 1 and 0 (which are the int/float TRUE and FALSE cast to, respectively), ‘1’ and the empty string (which are the string values TRUE and FALSE cast to), and ‘0’ (which (string)(int)FALSE would give you), along with objects casting to boolean. It’s not a perfect solution, but I currently feel that this is the most sensible option bar going for full strictness.

I’m not really decided, however. Every time I try to think about this, I usually end up going in circles. Anthony doesn’t seem to be decided either. Hence I’m putting this up for discussion.

What are your thoughts?

We are going round in circles as we are trying to second guess what programmers
will want - how they will try to use it. Part of the problem is that different
programmers will want different things AND the same programmer will want
different things in different parts of the program (think back to my 'inner' and
'outer' program parts).

One of the big items of discussion is: should this be a cast (ie convert to the
desired type) or a check (and error upon type mismatch). There are valid
arguments for both - indeed different use cases for both.

I will argue that they are not incompatible.

So: I see 3 cases and suggest a way of accomodating the different needs.

a) 'outer' code where types are not known, eg an argument might be something
from $_GET.

function CheckAge($age) {
if( is_numeric($age) && $age >= 0 && $age <= 150)
return TRUE;
// throw error/....
}

CheckAge($_GET['age']);

b) 'inner' code where something will have been checked to be convertable to the
desired type, but it might not be that type:

function CanLegallyDrive((int) $age) {
return $age >= 17;
}

if(CheckAge($_GET['age']) && CanLegallyDrive($_GET['age']))
....

Note the use of '(int)' to indicate that the argument should be cast to int.
If a conversion is not possible: the program errors in some nasty way.

The above is prob how this will often be used, so the cast rules should
reflect that, eg: '12' OK, '12 ' OK, '12a' Fail.

c) 'inner' code where the argument is known to be of the type and no convertion
will be done - if there is a type mismatch - generate an error.

function PrintMonth(int $month) {
    ...
}

for($mon = 0; $mon <= 12; $mon++)
    PrintMonth($mon)

I wanted to say something about function return types (good for optimisation)
but decided that that would risk of opening more cans of worms.

--
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256 http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php
#include <std_disclaimer.h

One of the issues with the RFC as it stands is how to handle bool casting. While int, float and string only allow lossless casting (with the exception of objects, but we can’t really do anything about that), bool’s behaviour at the moment is quite different. I don’t think it makes sense so I won’t discuss the current behaviour, only possible new ones.

Another option is go completely strict and allow only boolean values, failing everything else. This would be unlike the int, float and string hints, which are flexible and cast, but would be more helpful for catching bugs. However, not casting at all isn’t very “PHP-like”, and forcing people to manually cast with (bool) might not be ideal. If we were to go for this one, I might also accept objects casting to bool (which the default handler does), because I don’t want to stop extension developers from making bool-like objects if they so please.

I’ve made the patch and RFC do this, at least for the time being. I’m still not really decided, nor is Anthony. The main advantage of being completely strict is that it’s fully lossless; (bool)(string)$x === $x where $x was a boolean, but (string)(bool)$x !== $x where $x was a string. (Not necessarily, at least).

This would make it an oddball among the scalars as it’s completely strict, and would require you to cast to bool explicitly in many cases… but at the moment it seems to be the most sensible option to me.

Still, we’re both undecided.

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

Hi!

One of the issues with the RFC as it stands is how to handle bool
casting. While int, float and string only allow lossless casting
(with the exception of objects, but we can’t really do anything about
that), bool’s behaviour at the moment is quite different. I don’t
think it makes sense so I won’t discuss the current behaviour, only
possible new ones.

Most cases where bool is used is meant as "yes or no" parameter. In
those cases, getting non-boolean there may mean one of the following:

1. A complete error, passing wrong parameter by mistake.
2. Passing something that is meant to represent preference, but is not
   an actual boolean - i.e. null, empty string, string '1', object, etc.

Traditionally, many languages - including PHP - were lenient in
accepting non-boolean objects in boolean contexts - so you can say
if($obj) and mean "true if $obj is a real object, false if $obj is
something like false or null" instead of if((bool)$obj). In such
context, it is clear what the intent is, and the possibility of error is
very low.

However, when passing parameters the other option - one that implies the
error was passing a different parameter - is an option. The question is
how potential catching such error - noting that it would be caught only
if the other parameter is not boolean and the value is not boolean and
we do not use (bool) - is important over other considerations.

So here I would say we should take a consistent approach. By this I mean

• if we say scalar typing is coercive - i.e. if you say foo(bar $x), it
  means $x should be coerced into type "bar" or rejected if it does not
  make sense - then we should follow the general rules of boolean
  conversion and say any object can be turned into boolean, by the same
  rules as if() would take them.
  If, on the contrary, we take it as $x must be of type bar, or we reject
  it - then we should not accept anything but boolean. This however will
  lead us into strict typing, the concept which I personally oppose in
  this context, but would not elaborate further here since it was already
  done many times.

In any case, I think it is important to realize this decision is not
arbitrary, but connected to the rest of things - if you choose strict,
it makes no sense to be strict only in one place. If you choose
coercive, type casting rules should be consistent for all cases, not
special for every syntax.

work, anything you got from $_GET (e.g. ?foobar=1). However, this is
unlikely to catch bugs in code, because literally any PHP value would
work. For that reason, I’m not sure this is the way forward.

Making it strict would not help here - people would just be trained to
write (bool) everywhere, and thus the same bugs would be masked the same
way, only in much uglier code.

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

I am worried about this big casting conversion matrix. New rules should
not be invented, and the following should always be equivalent:

function foo(typehint $var)

vs:

function foo($var) {
$var = typehint $var;

In general, I am not in favour of casting typehints, as it would be a
different behaviour from the hard-check typehints that we already have
for classes and arrays.

I’ve talked about this before in this thread, but the justification for differing in behaviour from array and class hints is that these types are scalars (which PHP routinely juggles) and arrays and objects are not scalar (and not routinely juggled). While we are indeed casting, we’re only doing so where the conversion would be lossless. Sure, it’s not a hard check, but it is still quite strict. I don’t like the idea of completely strict type hints here, but I also don’t think that completely loose type hints that cast and do zero validation are for the best either. This RFC tries to strike a compromise.

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

Hi!

In general, I am not in favour of casting typehints, as it would be a
different behaviour from the hard-check typehints that we already have
for classes and arrays.

It already is. All internal functions behave this way.

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

The argument saying that it is not the PHP way is somehow incorrect
here, given that we already do that for classe. The type jungling
makes sense in implementations, as it always was but argument
passing
and validation have been a source of pain since very long. I could
imagine one exception with the "numeric" type, which could accept
anything and got converted to integer/numeric values, like "1235ab" or
other weird things.

Personal opinion of a nonvoter, just for the record :)

The fact that roughly everybody in the strict-and-validation camp in the
recent discussions, adds in a different view on "with the exception of",
very very strongly suggests that the strict-and-validation POV is wrong
wrong wrong.

On the one hand, because calling code will become sprinkled with
casts on function calls to coerce the arguments to conform to the strict
interpretation.

And on the other hand, because validation needs, for all practical
purposes, are far more finegrained than any half-a-dozen-type scheme.

So, I'm 100% in the cast camp, i.e. interpret scalar type annotation of
function arguments as syntactic sugar for explicit casts at the beginning
of the function.

best regards
Patrick

Hi,