[RFC] Scalar Type Hints

Hi Stas,

Hi!

Yeah, it’s a problem. I think some breakage here is inevitable,
unfortunately. Some of the classes with these names are stand-ins for
scalar type hints, so that code can “just” migrate to using actual
hints. But this doesn’t apply to all of them.

Breaking ZF2 and all software built on it is not "some breakage", it's a
serious issue which would produce a big barrier for PHP 7 migration. And
looks like there are more frameworks that do the same. This would be a
barrier to PHP 7 adoption, and note that is even for people that
couldn't care less for scalar typing. We'd find ourselves in python 3
situation - where people would be glad to upgrade but they use library X
and it doesn't work and they have no idea how to fix it and they keep
all their development on the old version and the new one never catches
on. It'd be a shame if we spend all this effort on PHP 7 and get no
adoption since people can't run their existing code on it.

I wouldn’t say it’s impossible to work around. You could rename the class to something which doesn’t conflict, but add a conditional class_alias for PHP 5. Codebases needing to work on both PHP 5 and PHP 7 can switch to the new name, codebases only needing to work on PHP 5 can stick with the old name.

Does that sound workable?

We could choose to simply not prohibit them as class names, but that
creates a weird inconsistency where you can make ‘class Integer’ yet
‘function foo(Integer $a)’ hints against the integer type, not your
class. Type hints are very widely used, so I doubt this would help
anyone, and we’d still be breaking existing code type hinting against
such classes.

I'd rather make the hints case sensitive. In fact, of two BC breakages
making classes case sensitive may be the lesser one (I'm not a big fan
of either but at least the modern frameworks would probably all work and
if some code does not it's possible to auto-fix it).

If they were case-sensitive, this would be inconsistent with other type names like array and callable.

Thanks!

Andrea Faulds
http://ajf.me/

ZF2 completely broke compatibility with ZF1 users, so I think this is a bad example.

Regards
Thomas

Stanislav Malyshev wrote on 02.01.2015 01:15:

Hi!

Yeah, it’s a problem. I think some breakage here is inevitable,
unfortunately. Some of the classes with these names are stand-ins for
scalar type hints, so that code can “just” migrate to using actual
hints. But this doesn’t apply to all of them.

Breaking ZF2 and all software built on it is not "some breakage", it's a
serious issue which would produce a big barrier for PHP 7 migration. And
looks like there are more frameworks that do the same. This would be a
barrier to PHP 7 adoption, and note that is even for people that
couldn't care less for scalar typing. We'd find ourselves in python 3
situation - where people would be glad to upgrade but they use library X
and it doesn't work and they have no idea how to fix it and they keep
all their development on the old version and the new one never catches
on. It'd be a shame if we spend all this effort on PHP 7 and get no
adoption since people can't run their existing code on it.

We could choose to simply not prohibit them as class names, but that
creates a weird inconsistency where you can make ‘class Integer’ yet
‘function foo(Integer $a)’ hints against the integer type, not your
class. Type hints are very widely used, so I doubt this would help
anyone, and we’d still be breaking existing code type hinting against
such classes.

I'd rather make the hints case sensitive. In fact, of two BC breakages
making classes case sensitive may be the lesser one (I'm not a big fan
of either but at least the modern frameworks would probably all work and
if some code does not it's possible to auto-fix it).

There’s not much we can do really. I suppose there is one positive
outcome, in that hopefully when broken code is updated to work, it
might have more descriptive class names. :)

The issue here is that people that now use ZF2 or other framework like
that won't rewrite it. They would just stay on PHP 5.

Stas Malyshev
smalyshev@gmail.com

Hey Sebastian,

It might add some value to forbid importing of unaliased type named
classes via use, so that no ambiguous type annotation exists.
Example:

use My\Lib\string as UserString; // fine, no error
use My\Lib\int; // Compile error: Forbidden to import scalar type. Use
as to create an alias

That’s something that was actually on my todo list. No point in forbidding class names if you can get around it with use.

Once I do this in the patch I’ll update the RFC to say as much.

Most libraries should be able to resolve such issues in a minor
release to stay compatible with PHP 7. If a user doesn't use PHP 7 he
won't be affected as the old import still works and the name of the
class (if namespaced) hasn't changed, if he switches to PHP7 the
updates can probably be automated.

Yes, this is possible. You could just rename the class to something that’s OK in both PHP 5 and 7 (IntClass, e.g.), then add a conditional class_alias() for PHP 5.

Actually, I’d need to update class_alias() as well. Hmm. Maybe I should make some sort of internal is_class_name_permitted() function.

Namespaced classes can still be named whatever they want as the
following(typehint an alias of the own class, using FQN) is already
valid and the signature of the method would not change(no major
release of a library required).:

namspace abc;
use abc\int as MyInt;

class int { function a(MyInt $a, \abc\int $b) ;}

I don’t like the idea of allowing these within namespaces, because relative uses would still be broken. Better to just force people to fix their class names.

Thanks.

Andrea Faulds
http://ajf.me/

Hi Stas,

I think it's perfectly acceptable that PHP makes a built-in type a
reserved word. I would certainly not change it to PHPInt to "avoid any
obvious clashes".

As I already pointed out, if we make it reserved word we'll have BC
problem. We already had this experience when goto became reserved word -
it resulted in a lot of breakage. This would be bigger, since we adding
more reserved words and we know they are used in a lot of class names
(and, possibly, method names too).

It is a BC problem, yes. However, it can be worked around in userland in a way where unchanged code will continue to work on PHP 5, and changed code will work on both PHP 5 and PHP 7. I think the BC break is worth it, though unfortunate. I also wonder why we hadn’t reserved these names before, it seems rather silly that you were ever able to make a class called “integer” or “array”.

By the way, we might want to pre-reserve resource as well. This RFC intentionally does not add a type hint for it, but we may wish to do so in future. It might also help with the migration to classes, too, as this would stop userland developers creating classes called “Resource” in the global namespace that would cause a future conflict.

Thoughts?

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

Hello Andrea,

I think it’d be weird to have different syntaxes for scalars and non-scalars. We already use the syntax the RFC proposes in the PHP manual, and I don’t think anyone’s confused by it.

I didn't meant to stay there's something wrong with the syntax, sorry if
my text was confusing! I was rather trying to point out that it does not
hint at anything but proactively tries to convert types; see below for more:

2. Casting and Validation Rules

"While this RFC merely follows PHP's existing rules for scalar
parameters, used by extension functions, these rules may not be familiar
to all readers of this RFC."

Yes and no. With the exception of hexadecimal numbers in strings, explicit casts and internal functions follow the same rules for conversion. However, the validation rules don’t match. Explicit casts never fail, while internal functions will reject arguments that are non-scalar or don’t fit certain rules.
[...]

3. "Non-numeric strings not accepted. Numeric strings with trailing
   characters are accepted, but produce a notice. "
   [...]

What's the point of continuing the code when developer asked for "int"
and code logic continues with "something not quite an int"?

Doesn't that defeat the whole purpose of the use of this RFC?
[...]

I can’t say I love that behaviour either. It is, however, our existing behaviour. I’d rather we be consistent with internal functions.

And as you also pointed out: those conversion rules are different from
what a plain "(int)$whatever" would do.

I completely understand the technical ratio here: internal function have
an existing argument/parsing system which is now exposed to the end
developer ("php user") here.

I argue this system is fit and works (and, err, talk BC; obviously!) for
the whole internal PHP function/method system but ..

.. does not reflect the needs and requirements of a php user/developer
because exactly of these implicit conversion rules with three different
output states (everything ok, hard type mismatch, notice on partial
conversion).

I'd also argue that scalar types in function signatures behaving
differently than object type hints is potentially a bad thing for future
of PHP and I already made my point which is the most important to me:

What's the point of continuing the code when developer asked for "int"
and code logic continues with "something not quite an int"?

Now, going on step back here (talking about me), I'm speaking up because

my< needs are developer are different (mostly speaking about backend
code, interfaces, libraries, frameworks) but OTOH I'm not a big known
open source framework developer either ;)

I would honestly be interested what the big framework/library players
actually want/need; do they prefer this implicit scalar type conversion
system or rather have a rigid system like the current object types but
for scalars too? I think decision on this RFC should include also
"their" saying too.

It's complex because we can't force anyone to participate but I think
above all these are the most important audience here because they know
what they want and they know what their users want. I say this because
usage of object types in PHP is almost non-existent (or, there are just
too few cases) compared to the architecture of some of the
framework/library systems out there.

Hmm.

thanks,

• Markus

genius and simple syntax!
int $a === assertInt($a)
(int)$a === (int)$a

2015-01-01 18:59 GMT+03:00 Marcio Almada marcio.web2@gmail.com:

The battle between strict type declarations vs coercive has been here for a
while. My problem with coercion in detriment of strictness is
that sometimes you DON'T WANT TYPE CASTING AT ALL. This new feature would
create serious impediments. So I wonder if we couldn't have both (strict
and coercive types declarations) and leave the current proposed type
hinting syntax reserved for strict type declarations? Like in:

function(int $a, (int) $b) {
     // $a will be strict
     // $b will be type casted
}

This way we can actually choose when to cast and when to be strict and both
features could be voted independently without affect each other possible
future adoptions.

--
With regards, Alexander Moskalev
irker@irker.net
irker@php.net
a.moskalev@corp.badoo.com

Woow. The compromise proposed by Marcio looks awesome to me :) .

Andrea, I can understand that in the PHP logic, but IMO if the RFC does not
avoid people that use code like I present before i don't think it's
completely relevant.
I mean, if people still use old tricks because the type hinting doesn't
allow to make what they wanted, then things are not cool enough and should
be re-think. And actually i say that because I see easily me still using
old trick without type hinting... Becaue of this cast story.

Also notice that Marcio's point could be another way, like adding something
with @integer (random operator choice, do not keep that in mind) that make
the check strict... Then IMO this operator will be so much used that it
will not make sence that is not the default behavior.
That's why the proposal of Marcio is cool to me.

2015-01-01 16:59 GMT+01:00 Marcio Almada marcio.web2@gmail.com:

The battle between strict type declarations vs coercive has been here for a
while. My problem with coercion in detriment of strictness is
that sometimes you DON'T WANT TYPE CASTING AT ALL. This new feature would
create serious impediments. So I wonder if we couldn't have both (strict
and coercive types declarations) and leave the current proposed type
hinting syntax reserved for strict type declarations? Like in:

function(int $a, (int) $b) {
     // $a will be strict
     // $b will be type casted
}

This way we can actually choose when to cast and when to be strict and both
features could be voted independently without affect each other possible
future adoptions.

The battle between strict type declarations vs coercive has been here for a
while. My problem with coercion in detriment of strictness is
that sometimes you DON'T WANT TYPE CASTING AT ALL. This new feature would
create serious impediments. So I wonder if we couldn't have both (strict
and coercive types declarations) and leave the current proposed type
hinting syntax reserved for strict type declarations? Like in:

function(int $a, (int) $b) {
     // $a will be strict
     // $b will be type casted
}

This way we can actually choose when to cast and when to be strict and both
features could be voted independently without affect each other possible
future adoptions.

for the record this was proposed (as an idea) previously with the exact
same syntax(the earlies mention I could find in my mailbox was from Derick
from 2009: http://comments.gmane.org/gmane.comp.php.devel/57653 but I
remember seeing it every time when this discussion happens).
If somebody is interested in previous attempts/discussion on the topic,
here are some links for starters:
http://nikic.github.io/2012/03/06/Scalar-type-hinting-is-harder-than-you-think.html
http://blog.ircmaxell.com/2012/03/parameter-type-casting-in-php.html
https://wiki.php.net/rfc/parameter_type_casting_hints
https://wiki.php.net/rfc/typechecking

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Hey Marco,

The problem is that the current proposed hints/casts are deviating from the type-hints that we are used to, therefore this particular feature should (eventually) have an alternate syntax, whereas the strict hints would just use int, integer, string, float, bool, boolan without additional chars (assuming that we will get strict hints somewhen).

I wouldn’t say it’s really such a great deviation. We use the same syntax for scalars and non-scalars in the manual.

This will also reduce clashes with the current HHVM implementation.

HHVM doesn’t have scalar type hints for PHP. Hack does, but Hack isn’t PHP.

Thanks.

Andrea Faulds
http://ajf.me/

The problem is that the current proposed hints/casts are deviating from the
type-hints that we are used to

I don't think type hints we currently have are different. The only difference we have is that there is no automatic casting for objects/arrays to scalars and scalars to objects/arrays (I exclude __toString() and $a=[]; echo $a;).

Regards
Thomas

Marco Pivetta wrote on 01.01.2015 17:56:

I think it is no problem to add strict parameter type hints with another
rfc (if this rfc gets accepted), e.g. function foobar(string! $str, int!
$str){} or any other syntax.

The problem is that the current proposed hints/casts are deviating from the
type-hints that we are used to, therefore this particular feature should
(eventually) have an alternate syntax, whereas the strict hints would just
use int, integer, string, float, bool, boolan without
additional chars (assuming that we will get strict hints somewhen).

This will also reduce clashes with the current HHVM implementation.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

Hi!

The problem is that the current proposed hints/casts are deviating from the
type-hints that we are used to, therefore this particular feature should

Let's check the manual we're used to.
http://php.net/manual/en/function.substr.php

string substr ( string $string , int $start [, int $length ] )

What "string" and "int" mean there? How they work? What we're
"deviating" from?

Stas Malyshev
smalyshev@gmail.com

Hey Levi,

I think it is no problem to add strict parameter type hints with another rfc (if this rfc gets accepted), e.g. function foobar(string! $str, int! $str){} or any other syntax.

I would rather have it the other way around. string $str is strict
and some other syntax (notably (string) $str or @string $str) can
be loose.

Rather than having it on a function-by-function basis, meaning different APIs would have different rules, I am warming to the idea of having a per-file strict mode. That is, if you used something like “use strict;” at the top of your code, functions you called would have strict parameter type checking. But if you didn’t, they’d be loose. This way all APIs would be consistent, but you’d have the choice of strictness or non-strictness as you see fit.

This would be similar to Hack’s Strict and Decl modes.

I’m not necessarily saying it’s the best idea, but it’s certainly an option. The syntax is already reserved! ;)

Thanks.

Andrea Faulds
http://ajf.me/

when looking into phpdoc, e.g. http://de.php.net/substr we have string and int everywhere in function definitions, do you want to change the whole documentation?

Regards
Thomas

Levi Morrison wrote on 01.01.2015 18:19:

I think it is no problem to add strict parameter type hints with another rfc
(if this rfc gets accepted), e.g. function foobar(string! $str, int! $str){}
or any other syntax.

I would rather have it the other way around. string $str is strict
and some other syntax (notably (string) $str or @string $str) can
be loose.

Hi!

I'm referring to consistency with existing non-scalar type declarations
supported by userland functions. They are strict.

There's no choice here as object types are not convertable in principle
(well, not unless we do convert ctors like C++ but IMHO that would be a
bit crazy). You can't equate primitive types in PHP with object types -
they just work differently and there can not be "consistency" between
them unless you rewrite PHP to be strongly typed language with no
implicit type conversion. It's not unheard of - Python is like that -
but it's not what PHP is now.

Furthermore it should be pointed out that scalars aren't much more
"convertable" than other types in PHP. For example it is possible to

That's not true - you can convert int to string, string to int, int to
bool, float to bool, etc. Most of these work implicitly - e.g. you can
do if($integer) and integer becomes bool. You can do "foo".$integer. You
can not have $integer->fileName() and have integer become some object
that has filename.

cast pretty much any value into an array (including scalars), yet nobody
is arguing that "array" typed parameters should accept integers as

That's because array is not a scalar type.
See
https://github.com/php/php-langspec/blob/master/spec/05-types.md#scalar-types
Try is_scalar([]).

Array is a collection type. Its behavior is different from scalars and
is more like objects (in fact, if it weren't for BC, it should have been
behaving exactly like objects and be just an object type, but that ship
has sailed).
Also, there's no implicit conversion from scalars to arrays. There's an
explicit one but that's different because explicit conversion is always
more powerful since it can assume you know what you're doing if you
asked to convert, so it should try harder.

input. PHP in general is very liberal with type conversions, this is not
specific to scalars.

It is specific to scalars - PHP is very liberal with implicit type
conversions of scalar types, but the only conversion you can do between
non-scalar types are degraded ones like object->array and
array->stdClass but even those are only for explicit cast - there are no
implicit casts between non-scalar types at all. That makes sense because
the semantic of non-scalar types leaves no place for implicit cast - you
can not just conjure a SplFileInfo out of object of another class, it's
too complex for that. There's a principal difference between scalars and
complex types in this regard.

By "vocal community" I'm referring to people who state an opinion on
this topic in a non-internals discussion. The scalar typehinting

Conveniently, there's no way to verify this claim. Not that random
assembly of reddit commenters is a representative group of anything but
a random assembly of reddit commenters.

of having strict type declarations. In various OTR conversations this
was also by far the most common opinion I heard.

So, you talk to people that think like you and share your opinion. That
must mean you're right or they are a majority of all PHP community?

proposal, and all other similar proposals I have seen, is that the
type check is value dependent. E.g. saying "integers and floats are
accepted for float parameters" is okay from a static analysis
perspective, whereas "strings are only accepted for int parameters if
they contain decimal integers" is not.

That depends on the purpose of your analysis. If your analysis is to
ensure the code never fails, type analysis would achieve very little.
What use would it be to know something is integer if you're taking
square root of it? You'd also need to know if it's not negative. And if
you're talking about bank balance withdrawal you'd also need to know
it's less than the current balance. And so on. You can not prove the
code works just by looking at types, especially shallow types like PHP has.
If your analysis, however, is the tool to ensure you didn't make obvious
mistakes - like returning an HTML page and thinking it's a number - weak
typing won't prevent anybody from discovering that.
Moreover, if your analysis is intended to help the optimizations - i.e.
after this point this variable is a known integer so I can drop all
IS_OBJECT checks and just add it to another integer - it would work too.
The only situation it wouldn't work is when you expect types to do
something types can't do anyway.

E.g. if even something obviously wrong like passing "foobar" to a
boolean argument cannot be detected as incorrect code (because it would

Why it's obviously wrong? There are many uses cases that passing
non-empty string to a boolean context is completely fine. For example:

$response = get_response();
if($response) {
ok();
do_stuff_with($response);
} else {
error();
}

It's completely fine and idiomatic PHP, why wouldn't you want to accept it?

be accepted by PHP), then I don't think doing type analysis would have
any value.

That's wrong, as I outlined above there are many cases where it could be
useful, so the approach of "do it my way or all is lost" is completely
unwarranted.

weak typehints on the other hand you will get away with working directly
on unvalidated input (like passing $_GET['id'] directly to an int-hinted
parameter). Usually. However when the script is called with ?id=abc you
will get a runtime error. That is what I'm referring to when I say "more

If "abc" is not a valid input for your logic, you'd get a runtime error
in any case.

Hack is very similar to PHP.

That's a weird case of logic inversion. You start with a claim that
"Hack is very similar to PHP", then you proceed to show a part of Hack
that is not very similar to PHP - namely, strict typing which PHP never
had - and then you claim this proves PHP should change. Maybe this just
proves Hack is not as similar to PHP as you previously thought?

If something works for Hack it is likely to
also work well for PHP.

Hack was written for one use case and its usage now is a tiny fraction
of PHP usage. We have no idea how anything Hack does would work on the
scale (both time and user-base wise) of PHP. Maybe it would work, maybe
it wouldn't. Claiming just because people designing Hack thought
something is a good idea automatically makes it a good idea for PHP is
completely baseless.

Be realistic. I'm not trying to sell you algebraic data types because
they're nice in Haskell, and I'm not trying to introduce Lisp macros
either. I'm talking about a language that is derived from PHP. I think

It is derived, that is true. But where it departs from PHP, there we
must be careful. Their derivation does not automatically makes PHP their
follower.

Hack is a nice playground for new PHP features and we should be
incorporating the parts that turned out to be useful.

For that, we need first to determine they are useful for PHP, not just
claim "Hack has it, so we must have it too". Especially when we talk
about the features which go contrary to the very principles on which PHP
is built. Maybe these principles do not work for you, maybe you'd prefer
a language with strict typing and more powerful type inference. That's
fine, there are languages for that. But when we're talking about making
PHP a strict-typed language, it's a different story and "other boys do
that" is not going to be a good argument.

correctness we allow only the specified type. I prefer correctness over
convenience, but I understand that others have different opinions on this.

When you say it's your preference, I completely understand you.
Everybody has their preferences and styles, some prefer more strict
languages, some prefer more relaxed one, some choose these and those
depending on context. But if we talk in terms of "majority", "useless
without it", etc. then there's much bigger disagreement than just
preferences.

Stas Malyshev
smalyshev@gmail.com

I don't necessarily have any more insight to provide than has already
been done, but I do want to chime in and say that I personally favor
strict types as Nikita Popov has been advocating.

Hi!

I am not sure about that. Parameters handling is one specific case,
userland parameter handling even more. It could be a good move to do

Making internal and userland parameters work differently and having
scalar type errors behave differently from object type errors by having
one throw exceptions and another errors looks like a mistake to me. It
only makes handling errors harder as you'd have to handle two types of
situations instead of one.

that as a 1st step, with this RFC.

I don't think "1st step" is a good approach here. The language should
provide consistent expectations, including about what happens when you
pass certain data to it, including error conditions. If we have
different types of error conditions between internal and userland
functions, it would not be a good thing.

We should make all parameter handling work the same way - so if you pass
a parameter and it does not match the expectations, you know what you're
getting. If it works one way to internals, another for user functions,
it would only make it harder to handle.

Stas Malyshev
smalyshev@gmail.com

Here is what I run on my ubuntu 14.04 for compiling & testing:

apt-get install build-essential re2c bison
git clone -b master https://github.com/php/php-src.git
cd php-src
curl https://github.com/php/php-src/pull/972.patch | git am
./buildconf
./configure
make
sapi/cli/php /tmp/test.php

test.php is my testing script.

Regards
Thomas

Sebastian B.-Hagensen wrote on 03.01.2015 20:46:

• on-numeric strings not accepted. Numeric strings with trailing
  characters are accepted, but produce a notice.

I would rather not allow fancy conversions here. Any trailing non
white spaces characters should not be allowed. I know it is not what
PHP does now in some cases but this is really a fuzzy area and never
really matched any actual needs or usages.

Yeah, I don’t like this behaviour much. I want to avoid inconsistency with
the behaviour of extension functions (i.e. zend_parse_parameters) where
possible, though. Since this has come up so much, I should probably make an
RFC to change this aspect of ZPP’s behaviour.

That RFC should probably be voted on before this RFC proceeds into voting.

After skimming through the RFC I'm unsure what the following code would
produce:

function test(int $a, int $b) {}

test("10.4", 10.6);

If a warning/notice is raised, fine. If it will just result in $a ===
(int)10 && $b ===(int)10 :

I agree that consistency is a sound reason for this behavior. However
type annotations (or whatever they will be called) should not only
ensure that a parameter has a certain type but that no data was lost
during the conversion. It is reasonable (assuming the target type can
handle the value) and fine to convert an integer into a float, a
float/integer to a string or any string that would satisfy is_numeric
into a float (or if no data was lost an integer) and hide it from the
developer (after all, that is was php is about). If a conversion might
result in data or precision loss the developer should be notified with
a hard failure. (E_RECOV, E_WARNING, I can still chose to ignore them
using error handlers or error_reporting settings).

Allowing data (I would also consider (string)'12a' => int(12) data
loss) or precision loss while converting a typed parameter would
reduce the usability of the whole addition.

If I'm in a situation where data loss is acceptable I could just leave
the annotation away and cast as I would've always done or not cast and
trust on php to do whatever is required.
However caring about data loss in these specific occasions( including
the string -> int example above) would forbid me to use type
annotations. As I would have no way of knowing and bailing out if the
original value was altered before it was accessible by my code.

If type annotations wouldn't go beyond the safety that php currently
provides by converting in specific contexts and casting what is the
benefit in adding them?

However, while I see issues with the RFC (that might be related to a
misunderstanding on my side) I like the general direction.

I am also not a fan of errors, exception, at least for methods, make
much more sense. I know it is relatively easy to handle errors as
exception but still, let do it right now.

That’s be inconsistent with our other type hints. To get this changed, I
think we’ll just have to wait for Nikita’s Exceptions in the Engine for
PHP 7 RFC.

Hi Sebastian,

Yeah, I don’t like this behaviour much. I want to avoid inconsistency with the behaviour of extension functions (i.e. zend_parse_parameters) where possible, though. Since this has come up so much, I should probably make an RFC to change this aspect of ZPP’s behaviour.

That RFC should probably be voted on before this RFC proceeds into voting.

That would be the idea.

After skimming through the RFC I'm unsure what the following code would produce:

function test(int $a, int $b) {}

test("10.4", 10.6);

If a warning/notice is raised, fine. If it will just result in $a ===
(int)10 && $b ===(int)10 :

The first argument would be converted to 10 and a notice (“Non well formed numeric string”). The second would also be converted to 10, but silently.

I agree with your sentiments about data loss, but I am reluctant to deviate much from the behaviour of internal functions to avoid the inconsistency that plagued the previous RFC.

If type annotations wouldn't go beyond the safety that php currently
provides by converting in specific contexts and casting what is the
benefit in adding them?

They’re still much safer than what we currently have. An unhinted parameter will accept anything. A scalar hinted parameter won’t accept non-scalars, and will only accept certain scalars.

Plus, they also avoid the need to use things like docblocks for many functions where merely adding types would make them self-explanatory.

Thanks.

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

Hi Pavel,

Hi, thanks for explaining some things.

It can sometimes be a lossless conversion. Only sometimes.

For float to int conversion:

• Floats have the special values INF, NAN and -NAN, which cannot be preserved
• Floats have negative zero, which also cannot be preserved
• Fractional components cannot be preserved
• Floats sacrifice precision to allow a wider range of values. They work with significant figures (scientific notation), unlike integers which always offer full precision. So a particular float value isn’t necessarily equivalent to a particular integer value, you have to invent precision to do the conversion. 2e10 is dealt with as if it’s 2 with 10 zeroes after it, but it’s just a number beginning with 2 that has a magnitude of roughly 10^10. If you convert it to the integer value 20 000 000 000, you’ve just invented values for those trailing digits - those digits weren’t necessarily zero, we just don’t know what those digits are. Someone who’s an expert on floating-point might need to correct me here, but I think this is correct to some extent. What I’m saying is that float->integer conversion is inherently imprecise.

For int to float conversion:

• Values beyond 2^53 or below -2^53 cannot be represented as floats without a loss of precision

Some strongly-typed languages allow these conversions implicitly, but I’m not sure that’s a good thing or something we should want to copy. Loss of precision isn’t good. If you ask for strict typing, you probably want to avoid it, and should get strict typing.

And being able to pass a float(1.5) to int and lose the 0.5 value
doesn't make sense as well, because data will get lost. Neither of
those feels somehow "predictable" and "natural”.

Sure, but it is our existing behaviour.

Yeah, as I said, implicit float to int is IMHO bad and I personally
don't like it much, because data loss sucks. But being consistent with
existing behavior is probably the right way to do stuff.

About the problem with int to float and loss of precision beyond 2^53:
I didn't realize that, was thinking just about 32bit integers when I
wrote that. But now I wonder how other languages do it, when they are
implicitly converting 64bit integers to double precision floating
point numbers.

Unfortunately we don’t have safe casting functions because they were rejected. Alas.

So, I think it would be best to choose just one of these two
approaches and either loosen it a little or make it more strict (so
data loss doesn't happen). But I guess this approach would be
inconsistent with how the built-in PHP functions work?

While it never went to a vote, the Scalar Type Hinting with Casts RFC, which proposed stricter weak casts, was not well-received. The Safe Casting Functions RFC was rejected when it went to a vote.

Oh, I didn't know that stricter weak casts were not well-recieved,
because I didn't read internals mailing list back then. But if that's
the case, I would gladly see the weak variant of this RFC accepted.
Have you thought about splitting this RFC into two? One for adding the
weak version and another one for adding the declare strict statement?

The Scalar Type Hinting with Casts RFC didn’t do that, it was also based on values.

In a dynamically-typed language like PHP, I don’t see why it needs to be type-based rather than value-based.

Maybe I wrote it wrong; I knew the old RFC had conversions based on
values. I just thought the rules based on types (you definitely know
what you need to convert and what not before calling a function) would
make much more sense, but the problem with 2^53 means that the
typed-based conversions are not a great solution either.

Pavel Kouril