Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83470
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain tutteli.ch designates 80.74.154.78 as permitted sender)
To: "'Zeev Suraski'" <zeev@zend.com>,
	"'PHP internals'" <internals@lists.php.net>
References: <7ef509ef10bb345c792f9d259c7a3fbb@mail.gmail.com>
In-Reply-To: <7ef509ef10bb345c792f9d259c7a3fbb@mail.gmail.com>
Date: Sun, 22 Feb 2015 14:09:53 +0100
Message-ID: <002101d04ea0$d92ea0f0$8b8be2d0$@tutteli.ch>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQKcPg+jpyYspJS11b5G1A7RBHpKTptj0TZg
Content-Language: de-ch
Subject: AW: [PHP-DEV] Coercive Scalar Type Hints RFC
From: php@tutteli.ch ("Robert Stoll")

Hi Zeev,

> -----Urspr=C3=BCngliche Nachricht-----
> Von: Zeev Suraski [mailto:zeev@zend.com]
> Gesendet: Samstag, 21. Februar 2015 18:22
> An: PHP internals
> Betreff: [PHP-DEV] Coercive Scalar Type Hints RFC
>=20
> All,
>=20
>=20
>=20
> I=E2=80=99ve been working with Fran=C3=A7ois and several other people =
from internals@ and the PHP community to create a single-mode
> Scalar Type Hints proposal.
>=20
>=20
>=20
> I think it=E2=80=99s the RFC is a bit premature and could benefit from =
a bit more time, but given the time pressure, as well as the fact
> that a not fully compatible subset of that RFC was published and has =
people already discussing it, it made the most sense to
> publish it sooner rather than later.
>=20
>=20
>=20
> The RFC is available here:
>=20
>=20
>=20
> wiki.php.net/rfc/coercive_sth
>=20
>=20
>=20
> Comments welcome!
>=20
>=20
> Zeev

First of all, thank you and all others working on this RFC but also =
people working on another RFC related to scalar type hints. It is good =
that PHP will get scalar type hints eventually.

Although I think the strict mode as proposed in the v0.5 RFC is nice as =
such, I prefer this RFC simply by the fact that it does not introduce =
different modes. I genuinely believe that different modes will be very =
harmful for PHP.
Yet, this RFC is not perfect either. IMO PHP is not ready for scalar =
type hints, not for PHP 7.0 respectively and we should instead focusing =
on clearing the way for the introduction of scalar type hints in PHP 7.x =
and hence introduce all required BC breaks in PHP 7.0 which are =
necessary in order that scalar type hints can be added to PHP 7.x later =
on.=20

I am provoking on purpose of course. But rightly so, because I think in =
all the debate about strict/weak scalar type hints we lost focus on what =
really matters in language growth, namely its maturation.=20

For instance, Pierre and others carped about that string -> bool and =
float -> bool are accepted by this RFC. While I agree that it is a bad =
idea to apply implicit conversions to such input  (I would not even =
allow int -> bool to be honest), it makes totally sense for PHP to =
behave like this at the moment. I would even claim that null, array, =
object, literally everything should be accepted as well since the =
explicit (bool) accepts everything as well and some implicit castings =
such as the one in an if statement accepts also everything.=20

From questions like these:
> Boolean STH (bool):
> this is by far too weak. How strings could be consider as valid, how?
> "true" > Boolean true? I suppose then "false" will be boolean false?
> What's is the boolean value of float 0.5?
> At the very least only integer should be accepted, 0 > false, anything =
>=3D1 true

I get the impression that even internals start to get confused about the =
conversion rules PHP has. Implicitly convert something to bool should be =
exactly the same as an explicit conversion (thus straight forward to =
verify http://3v4l.org/nVgbG ).
We should start to eliminate the different behaviour of =
implicit/explicit castings [1], to have a consistent and =
predictable/obvious behaviour in the long run. Or in other words, and =
that is what I meant above, PHP's type system needs to mature. While I =
can understand that it looks beneficial to have all kind of reliefs for =
the beginner, it is rather harmful in the long run. PHP has so many =
inconsistencies and requires a user to be aware of all kind of edge =
cases that I think bugs are introduced more frequently than necessary. =
We already have different conversion mechanisms in PHP and I guess the =
reason why https://wiki.php.net/rfc/safe_cast was declined is based on =
the fact that most people did not want to see yet another group of =
conversion rules.

There were people claiming that PHP follows the philosophy that a user =
does not need to know anything about scalar types. PHP will deal with it =
via type juggling. A function/operator requires an int? Just pass a =
scalar and PHP will convert it automatically via type juggling to int.=20
That is long gone (probably was never there) because the user had to =
know exactly what type can be passed or rather what values, otherwise =
bugs are inevitable. Consider the following:

 "a" % 1;
fmod("a", 0.5);

Kind of logical that % accepts any kind of scalar where fmod does not, =
right? I do not want to exaggerate too much on this but I think you get =
my position that PHP needs to get rid of this inconsistencies rather =
than adding yet another obstacle which impedes to reach consistency. =
Once scalar type hints are in place it should follow the conversion =
rules which we want to have in PHP in the long run otherwise the BC =
impact it would have to change them would be too big and we would at =
least need to wait till PHP 8 if not even PHP 9.

So what does that mean for scalar types?
IMO it means that way more important than adding scalar type hints to =
PHP 7.0 is to agree on a new set of conversion rules for the long run. =
PHP should strive to have one consistent set of conversion rules which =
apply in all places where implicit or explicit conversion are used. =
Hence, the way (bool) works in the future needs to change as well [2]. =
That is my opinion. I am aware of that such a change would have a way to =
big BC break impact for PHP 7.0 (likewise the option 1 of this RFC). But =
can be introduced step by step [3] (kind of my choice of option) and =
migration tools could facilitate the migration to a new version. I think =
I am not alone with this opinion (I just read the email of Shashank)=20

I see the migration plan roughly as follows:

PHP 7.0:
  - reserve keywords: bool, int, float including alternatives
  - deprecate alternative type names such as boolean, integer etc.

  - introduce new conversion functions which reflect the current =
behaviour of (bool), (int) etc.
      --> as mentioned above, they could be named =
oldSchoolBoolConversion etc.=20
      --> Encourage users to use this function instead of (bool), (int) =
etc since (bool) etc. will change with PHP 8.0. Also mention, that this =
function should only be used if the weakness is really required =
otherwise use the new conversion functions from below

  - introduce new conversion functions which reflect the new defined =
conversion rule set (which shall be the only one encouraged in the =
future) Those functions shall trigger an E_RECOVERABLE_ERROR=20
    --> encourage users to use this functions instead of (bool), (int) =
and oldSchoolBoolConversion etc.  (unless the weakness is really =
required, then use oldSchoolBoolConversion)

  - update the docs in order to reflect the new encouraged way. Also =
mention that:
     - (bool), (int) etc. will change their behaviour in PHP 8.0
     - internal functions will use the new conversion rules if not =
already done this way in PHP 8.0 (for instance, strstr will no longer =
accept a scalar as third parameter in the case where we do not support =
implicit casts to bool) =20
     - operators will use the new conversion rules if not already done =
this way in PHP 8.0
     - (control structures will use the new conversion rules if not =
already done this way in PHP 8.0) =3D>Maybe this is too strict for most =
of you and goes against the spirit of PHP (I suppose some of you will =
say that - fair enough, I guess you are right). In this case, I would at =
least use the term "loose comparison" as mentioned here: =
http://php.net/manual/en/types.comparisons.php#types.comparisions-loose =
instead of using the term "conversion", then it is compatible with the =
changes introduced in PHP 8.0

PHP 7.1: necessary bug-fixes introduced with PHP 7.0
PHP 7.x: deprecate even more if required
PHP 8:=20
  - introduce scalar type hints which reflect the conversion rules as =
defined (adding strict type hints as well is possible of course, whether =
with an ini-setting, a declare statement or individually with a modifier =
something like "strict int" for a single parameter or strict function =
for all parameters incl. return type or strict class for every type =
defined in the class is up to discussion)
  - exchange the behaviour of (bool), (int) etc. -> use the new =
conversion rules instead
  - change internal functions which do not yet obey to the new =
conversion rules
  - change the operators which do not yet obey to the new conversion =
rules (for instance, + would also emit an E_RECOVERABLE_ERROR for "a" + =
1)
  - (change the control structures in order that they obey the new =
conversion rules as well) =3D> as mentioned above, probably too strict =
for PHP

Back to this RFC.  think this RFC goes in the right direction with the =
specified conversion rules. Only thing to get rid of are the implicit =
conversions to bool from string, float and int IMO.
Moreover, I like that the RFC already has different steps for adding the =
new behaviour. Yet, I think it should slow down a little bit as shown. I =
think we need more time to come up with a very good strategic solution.

Thoughts?
=20
Cheers,
Robert

[1] for instance, that implicit/explicit conversion behaves differently =
and that the implicit conversion in an if statement uses yet another =
behaviour. Operator signatures and function signatures behave =
differently, control structures and functions behave differently etc.

[2] (bool) would not longer accept all kind of input data - IMO it would =
not accept anything, PHP does not support conversions to bool. I would =
even change the way if works and disallow if(new Foo()){} for instance =
(since no conversion to bool exist anymore). PHP could add a function =
which behaves like the current (bool), maybe oldSchoolBoolConversion =
(ugly name in order that no one is encouraged to use it) and users would =
need to write if(oldSchoolBoolConversion(new Foo())){} to get the same =
behaviour as today.=20