Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83472
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain richgray.com from 209.85.212.180 cause and error)
Message-ID: <54E9E3A9.1010305@richgray.com>
Date: Sun, 22 Feb 2015 14:11:53 +0000
Reply-To: rich@richgray.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Robert Stoll <php@tutteli.ch>, 'Zeev Suraski' <zeev@zend.com>, 
 'PHP internals' <internals@lists.php.net>
References: <7ef509ef10bb345c792f9d259c7a3fbb@mail.gmail.com> <002101d04ea0$d92ea0f0$8b8be2d0$@tutteli.ch>
In-Reply-To: <002101d04ea0$d92ea0f0$8b8be2d0$@tutteli.ch>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: AW: [PHP-DEV] Coercive Scalar Type Hints RFC
From: rich@richgray.com (rich gray)

On 22/02/2015 13:09, Robert Stoll wrote:

[snip]

...
> 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 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) => 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?
>   
+1 - good analysis - a single mode approach with consistent type 
coercion rules across the board makes absolute sense even if STH are put 
back until PHP 8.x