Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83474
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.54 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <002101d04ea0$d92ea0f0$8b8be2d0$@tutteli.ch>
References: <7ef509ef10bb345c792f9d259c7a3fbb@mail.gmail.com>
	<002101d04ea0$d92ea0f0$8b8be2d0$@tutteli.ch>
Date: Sun, 22 Feb 2015 15:54:06 +0100
Message-ID: <CAB6YZuzKZAiSbzq7+yOsZ4wqKMTR1myemuPqEsDUAqpNzMnHBg@mail.gmail.com>
To: Robert Stoll <php@tutteli.ch>
Cc: Zeev Suraski <zeev@zend.com>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Coercive Scalar Type Hints RFC
From: pajousek@gmail.com (=?UTF-8?Q?Pavel_Kou=C5=99il?=)

On Sun, Feb 22, 2015 at 2:09 PM, Robert Stoll <php@tutteli.ch> wrote:
>
> 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 behaviou=
r of (bool), (int) etc.
>       --> as mentioned above, they could be named oldSchoolBoolConversion=
 etc.
>       --> Encourage users to use this function instead of (bool), (int) e=
tc since (bool) etc. will change with PHP 8.0. Also mention, that this func=
tion should only be used if the weakness is really required otherwise use t=
he new conversion functions from below
>
>   - introduce new conversion functions which reflect the new defined conv=
ersion rule set (which shall be the only one encouraged in the future) Thos=
e functions shall trigger an E_RECOVERABLE_ERROR
>     --> encourage users to use this functions instead of (bool), (int) an=
d oldSchoolBoolConversion etc.  (unless the weakness is really required, th=
en use oldSchoolBoolConversion)
>
>   - update the docs in order to reflect the new encouraged way. Also ment=
ion that:
>      - (bool), (int) etc. will change their behaviour in PHP 8.0
>      - internal functions will use the new conversion rules if not alread=
y done this way in PHP 8.0 (for instance, strstr will no longer accept a sc=
alar as third parameter in the case where we do not support implicit casts =
to bool)
>      - operators will use the new conversion rules if not already done th=
is way in PHP 8.0
>      - (control structures will use the new conversion rules if not alrea=
dy done this way in PHP 8.0) =3D>Maybe this is too strict for most of you a=
nd goes against the spirit of PHP (I suppose some of you will say that - fa=
ir enough, I guess you are right). In this case, I would at least use the t=
erm "loose comparison" as mentioned here: http://php.net/manual/en/types.co=
mparisons.php#types.comparisions-loose instead of using the term "conversio=
n", 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:
>   - introduce scalar type hints which reflect the conversion rules as def=
ined (adding strict type hints as well is possible of course, whether with =
an ini-setting, a declare statement or individually with a modifier somethi=
ng like "strict int" for a single parameter or strict function for all para=
meters incl. return type or strict class for every type defined in the clas=
s is up to discussion)
>   - exchange the behaviour of (bool), (int) etc. -> use the new conversio=
n 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 rule=
s (for instance, + would also emit an E_RECOVERABLE_ERROR for "a" + 1)
>   - (change the control structures in order that they obey the new conver=
sion 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 sp=
ecified conversion rules. Only thing to get rid of are the implicit convers=
ions 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 th=
ink we need more time to come up with a very good strategic solution.
>

Hello,

Am I understanding correctly that you are suggesting changes to type
casting? This seems like a bad idea. Explicit and implicit conversions
are something really different. Generally, implicit conversions are OK
only when no data is lost and explicit conversions (casts) are used
when you realize some information can get lost and you still want to
proceed with the conversion. Having only one type of conversion is
IMHO weird.

Also, I'm not a fan of having to wait for scalar type hints for few
more years. :(

Regards
Pavel Kouril