Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84559
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain outlook.com designates 65.54.190.91 as permitted sender)
Message-ID: <BAY178-W5945DBF18D50C0F91C760DE190@phx.gbl>
To: "zeev@zend.com" <zeev@zend.com>
CC: "internals@lists.php.net" <internals@lists.php.net>
Date: Wed, 11 Mar 2015 12:11:20 -0500
Importance: Normal
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [VOTE][RFC] Coercive Scalar Type Hints
From: theodorejb@outlook.com (Theodore Brown)

Zeev=2C=0A=
=0A=
> The vote on the Coercive Scalar Type Hints is now open for voting.=0A=
> =0A=
> The latest version of the RFC includes changes discussed on internals@ la=
st=0A=
> week:=0A=
> =0A=
> 1.=A0 Accept string->bool and int->bool conversions (false->bool is not=
=0A=
> supported)=0A=
> 2.=A0 Accept leading/trailing spaces in string->number conversions.=0A=
> =0A=
> wiki.php.net/rfc/coercive_sth=0A=
> wiki.php.net/rfc/coercive_sth#vote=0A=
> =0A=
> Thanks!=0A=
> =0A=
> Zeev=0A=
=0A=
The proposed coercion rules aren't clear. The first table in the RFC implie=
s=0A=
that string is accepted for bool hints=2C and the second table says this is=
=0A=
unchanged. But the examples section states that "foo" -> bool will raise an=
=0A=
E_DEPRECATED error. I'm guessing this is a mistake=2C since you mentioned=
=0A=
above that string->bool is accepted.=0A=
=0A=
You also stated above that false->bool is not supported (I'm guessing you=
=0A=
meant float->bool). So users would be able to pass "4.3" to a bool typehint=
=2C=0A=
but not 4.3? This behavior seems very arbitrary and confusing.=0A=
=0A=
Not only would this RFC introduce backwards compatibility breaks in a futur=
e=0A=
PHP release=2C but it still doesn't bring the same opportunities for static=
=0A=
analysis which the optional strict mode in Anthony's proposal enables.=0A=
=0A=
The coercive RFC misleadingly contradicts itself by stating that "we don't=
=0A=
believe that is the case" "that Strict STH can help static analysis in=0A=
certain cases" "although it's possible that Strict Typing may be able to=0A=
help static analysis in certain edge cases." Do you believe it will help in=
=0A=
certain cases or not?=0A=
=0A=
Strict types can absolutely help - not only for static analysis=2C but also=
=0A=
for potential future AOT/JIT development. Why? Because only types need to=
=0A=
be checked=2C rather than values. This is why an optional strict type syste=
m=0A=
in JavaScript makes it possible for Google to make "early and aggressive=0A=
optimisations" in V8 (see https://developers.google.com/v8/experiments).=0A=
It also makes it possible to catch errors earlier in development (see the=
=0A=
example in my "A different user perspective on scalar type declarations"=0A=
email). As a developer of large enterprise applications=2C these benefits=
=0A=
are very important to me.=0A=
=0A=
> Static Analyzers need to be designed for Languages=2C rather than Languag=
es=0A=
> being designed for Static Analyzers.=0A=
=0A=
You really have this backwards. Why do you think Facebook created Hack?=0A=
Why did Microsoft create TypeScript? Why are there serious discussions=0A=
to add optional strict typing to ECMAScript proper?=0A=
=0A=
Theodore Brown=0A=
 		 	   		  =