Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83075
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>
Cc: "'Sara Golemon'" <pollita@php.net>,
	"'PHP internals'" <internals@lists.php.net>
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> <34ad95db84909d07feb98dbe76f7d52c@mail.gmail.com>
In-Reply-To: <34ad95db84909d07feb98dbe76f7d52c@mail.gmail.com>
Date: Wed, 18 Feb 2015 15:55:12 +0100
Message-ID: <006b01d04b8a$e6564d50$b302e7f0$@tutteli.ch>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQKz6wpj8b81mnwJq1LfxWbU4ZJyQgGjcksIAbrU1N8Bn0wufQGLyLi6ApOAQNgCKs4UBZrU+wzw
Content-Language: de-ch
Subject: AW: [PHP-DEV] Scalar Type Hints v0.4
From: php@tutteli.ch ("Robert Stoll")

> -----Urspr=C3=BCngliche Nachricht-----
> Von: Zeev Suraski [mailto:zeev@zend.com]
> Gesendet: Mittwoch, 18. Februar 2015 14:03
> An: Robert Stoll
> Cc: Sara Golemon; PHP internals
> Betreff: RE: [PHP-DEV] Scalar Type Hints v0.4
>=20
> > -----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).
> > Just from reading the original code I would suspect that strstr
> > expects some kind of an offset (hence the int), therefore strict =
mode
> > probably revealed a bug.
>=20
> 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.

[Robert Stoll]=20
Sorry, I was probably not clear enough. I just tried to illustrate what =
internally happens, how the code could look like after the implicit =
conversions were added. I am aware of that this was oversimplified since =
the implicit conversions do not correspond to the explicit ones (which =
is inconsistent IMO but this is another story).
The point I tried to make is, that the following code is not very =
readable (is misleading) and that the lack of strictness results in =
unnecessary implicit conversions:

function foo(string $x, int $y){
   bar(1);
  return strstr($x,"hello", $y);
}

- The implicit conversion of 1 to float is unnecessary (and thus an =
extra cost) - the user should have written 1.0
- The implicit conversion from $y to bool hides that strstr expects a =
bool as third argument and hence hides a potential bug

Two use cases where strict mode would be beneficial. However, the first =
case is not so dramatic. PHP is not a high performance language and thus =
it is perfectly fine IMO to have unnecessary implicit conversions. Yet, =
the latter point is a use case where I would like to have strict mode. =
Same for the following:

$a =3D strpos("hello","h");
if($a){}

if the condition of the if statement would be strict I could not have =
introduced this very common bug.

> Explicit casts are actually use a much more aggressive ruleset than =
even the 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.

[Robert Stoll]
Aye, a pity that safe casting functions where rejected: =
https://wiki.php.net/rfc/safe_cast
But maybe this discussion revive the RFC

> Secondly, I think there aren't any common situations where strict =
typing (in 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.
>

[Robert Stoll]=20
I was not clear enough, I merely meant unnecessary casts are costly

> 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.

[Robert Stoll]=20
I share this view, as I stated below, strict mode only makes sense with =
safer casts IMO. I think it would be clever to agree on the way "safe =
casts" should work, expose them to userland and if we should not get =
scalar type hints into PHP 7.0 then we have at least safe cast functions =
which allow almost the same but with a bit more code.

>=20
> > And if not, then one can add the conversion manually. However, this =
is
> > not 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. What 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"]);
>=20
> 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").
>=20
> Zeev