AW: [PHP-DEV] What do we need strict scalar type hints for?

> -----Ursprüngliche Nachricht----- > Von: Dmitry Stogov [mailto:dmitry@zend.com] > Gesendet: Mittwoch, 4. Februar 2015 10:26 > An: Sebastian Bergmann > Cc: PHP Internals > Betreff: Re: [PHP-DEV] What do we need strict scalar type hints for? > > hi Sebastian, > > Do you like the proposal with declare() switch? > Don't you afraid of sin(1) break? (it's just an example, telling how many things may > be broken). > > Thanks. Dmitry. > > On Wed, Feb 4, 2015 at 10:30 AM, Sebastian Bergmann <sebastian@php.net> > wrote: > > > Am 04.02.2015 um 08:25 schrieb Dmitry Stogov: > > > The idea of that RFC was an ability to have zero-cost assert(). > > > > But an assert() is still in the body of a function or method and not > > part of its signature. That is what I want scalar type declarations > > for. > > > > > > -- > > PHP Internals - PHP Runtime Development Mailing List To unsubscribe, > > visit: http://www.php.net/unsub.php > > > > Personally I am not in favour of the declare approach because the user will need to switch between strict context and non-strict context which will be quite challenging, anti-efficient (in terms of productivity) and most probably another source for bugs. Yet, I have to defend Andrea's RFC here since the claims made that it will break all kind of existing code is just not true (or I got the RFC completely wrong). sin(1) would only be broken if and only if the user has decided to use it in a strict mode. Consider the following: User A writes the file index.php <?php $a = sin(1); //perfectly fine include 'test_strict.php' ?> and user B writes test_strict.php <?php declare(strict=1); $b = sin(1); //will fail and that's ok [*] since the user decided to be in strict mode ?> As far as I can tell user A which want to code in non-strict mode could do so also in the future - no error is reported, no problem at all. Only user B would get the error and only because he/she wanted to be informed when his/her code is not strict. [*] we could actually distinguish between int literals/constants and int variables. The above case would be fine as well since 1 can be int or float (pretty much as Haskell is handling it)