Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83060
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.213.178 as permitted sender)
References: <CAESVnVoZYiMWQk1Ydc-9wbkJo7Ru_4mrUtrubW=Rh=QKK9o8TA@mail.gmail.com>
	<CAF+90c_S3xT07F-4smHeD=BTuSG9VQZxZ==mhyOzDuBw5QPX_Q@mail.gmail.com>
	<54E3E27B.2010903@lerdorf.com> <CAF+90c8o8GtO9=7JJ3Jmjzg-=qVAD1aiQaU32joOeD6XH_f4hg@mail.gmail.com>
 <2f99c47df51fa6c73131032ec50fade0@mail.gmail.com> <005201d04b6c$1122d130$33687390$@tutteli.ch>
In-Reply-To: <005201d04b6c$1122d130$33687390$@tutteli.ch>
MIME-Version: 1.0
Thread-Index: AQKz6wpj8b81mnwJq1LfxWbU4ZJyQgGjcksIAbrU1N8Bn0wufQGLyLi6ApOAQNia5jCicA==
Date: Wed, 18 Feb 2015 15:03:06 +0200
Message-ID: <34ad95db84909d07feb98dbe76f7d52c@mail.gmail.com>
To: Robert Stoll <php@tutteli.ch>
Cc: Sara Golemon <pollita@php.net>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: RE: [PHP-DEV] Scalar Type Hints v0.4
From: zeev@zend.com (Zeev Suraski)

> -----Original Message-----
> From: Robert Stoll [mailto:php@tutteli.ch]
> Sent: Wednesday, February 18, 2015 1:14 PM
> To: 'Zeev Suraski'; 'Nikita Popov'; 'Rasmus Lerdorf'
> Cc: 'Sara Golemon'; 'PHP internals'
> Subject: AW: [PHP-DEV] Scalar Type Hints v0.4
>
> > -----Urspr=C3=BCngliche Nachricht-----
> > Von: Zeev Suraski [mailto:zeev@zend.com]
> > Gesendet: Mittwoch, 18. Februar 2015 08:00
> > An: Nikita Popov; Rasmus Lerdorf
> > Cc: Sara Golemon; PHP internals
> > Betreff: RE: [PHP-DEV] Scalar Type Hints v0.4
> >
> > I am wondering what the point is indeed with preventing "123" to 123.
> > So far, all the concrete use cases people brought up had to do with
> > "Apple" or
> > "100 dogs", but nobody ever seems to be able to explain why converting
> "123"
> > to 123 is likely to be a problem real world.  Is it really just static
> > analyzers?
> >
>
> Strict mode is useful in the sense that it prevents unnecessary implicit
> conversions (which are costly) and it improves readability.
> Following an example:
>
> function foo(string $x, int $y){
>   bar(1);
>   return strstr($x,"hello", $y);
> }
>
> function bar(float $a){}
>
> After adding the implicit conversions the code would look as follows:
>
> function foo(string $x, int $y){
>   bar((float) 1);
>   return strstr($x, "hello", (bool) $y); }
>
> function bar(float $a){}
>
> In strict mode the original code would not be valid (rightly so IMO). Jus=
t
> from
> reading the original code I would suspect that strstr expects some kind o=
f
> an
> offset (hence the int), therefore strict mode probably revealed a bug.

There are two things I'm not so clear about in what you're saying.
It seems that the 2nd sample adds explicit casts and not implicit casts.
Explicit casts are actually use a much more aggressive ruleset than even th=
e
ruleset in the v0.3 RFC, in the sense that they'd happily convert "Apple"
into (float) 0.0, if you do an explicit (float) cast.  They (almost) can't
fail.
Secondly, I think there aren't any common situations where strict typing (i=
n
the form of zval.type comparison) would be any less costly than weak typing=
.
The difference is really between failure (abort in case there's a type
mismatch in strict) and success (convert to the requested type).  The
conversion that may happen in the weak scenario is no costlier than an
explicit cast, probably a tiny bit less actually.

Again, in my opinion pushing users towards explicit casts - which have much
more lax rules than the ones proposed in v0.3, let alone the ones we're
currently considering, will defeat the purpose and actually make finding
bugs harder.

> And if not, then one can add the conversion manually. However, this is no=
t
> as
> trivial as it sounds. Personally I think it would only make sense to have
> strict
> mode in PHP if the user had more strict conversion functions at hand. Wha=
t
> is
> the benefit of the following? if the conversion to int is as sloppy as
> today
> then one does not gain anything from the strict mode IMO:
>
> function foo(int $x){}
> foo( (int)$_GET["bla"]);

I agree, but changing the rules of explicit casts is a *huge* change and BC
break.  If we do implement the single-mode, stricter-than-pure-weak and
weaker-than-pure-strict ruleset, we could introduce a new set of conversion
functions, along the lines of safe_int(), that would follow the same rules
as the corresponding type hints (i.e. accept (int) 32, (string) "32", but
not (float) 32.7, or (string) "32 dogs").

Zeev