Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82992
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 212.27.42.2 as permitted sender)
Reply-To: <francois@php.net>
To: "'Anthony Ferrara'" <ircmaxell@gmail.com>,
	"'Zeev Suraski'" <zeev@zend.com>
Cc: "'Sara Golemon'" <pollita@php.net>,
	"'PHP internals'" <internals@lists.php.net>
References: <011801d04a07$83ab1c00$8b015400$@php.net>	<CABDNdAFQsbo-A-gijPCwYDOf3ts-yKpP0tAL--WUaLU26GB-AQ@mail.gmail.com>	<016f01d04a3a$e9183220$bb489660$@php.net>	<CAESVnVoM7YbmXA8hTG1O66j+6YX3Xx2Q3uj_F=TPjHA4ws=8JA@mail.gmail.com>	<d8031ce52e9965c789887e8f7b687a4e@mail.gmail.com>	<CAESVnVpA+M6iv_zbDmKTEF8Q1zKjwnbi1ucc=UyuUyRr+X+U3w@mail.gmail.com>	<022801d04ab1$4a0c47d0$de24d770$@php.net>	<1913e09d7f52541901d8574d2080a63f@mail.gmail.com> <CAAyV7nFD=BQ5dBYiKzhbOKTomKmWvruTnb=R_n9mYB-Lz1P9pg@mail.gmail.com>
In-Reply-To: <CAAyV7nFD=BQ5dBYiKzhbOKTomKmWvruTnb=R_n9mYB-Lz1P9pg@mail.gmail.com>
Date: Tue, 17 Feb 2015 18:46:26 +0100
Message-ID: <025f01d04ad9$a77a8e90$f66fabb0$@php.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQGD0sLDaA+/0NIeBlQhQC5OtPA/xwHih9+6AanvcsEBj7eMCwEU0CpMAs0H7+gBDwGZjwJNu28fAX8sxVSdHyZlkA==
Content-Language: fr
Subject: RE: [PHP-DEV] Reviving scalar type hints
From: francois@php.net (=?utf-8?Q?Fran=C3=A7ois_Laupretre?=)

Hi Anthony,

I understand your concerns and think the work we are doing should be =
suitable to compilers and static analyzers, but that's hard to make =
everyone happy.

One thing I thought we should reserve for a future release is the =
addition of a set of strict type hints : something like (just example =
syntax) 'int!', 'float!', 'string!', 'bool!' (other types are strict =
already). These types would have their counterpart at the ZPP level and =
their parsing rule would be to reject everything except the =
corresponding zval type.

This way, the user can write :

function convertToInt(string $number): int! {		<- int! instead of int
     if (!preg_match("(^[0-9]{1,17}$)", $number)) {
         throw new InvalidArgumentException("Supplied argument is not a =
valid number");
     }
     return $number;
 }

Which makes it usable for static analysis, I guess. These would be =
primarily used for return types.

Another valuable type would be something like 'numeric!', which could =
accept IS_LONG and IS_FLOAT only. This would be interesting for static =
analysis, to know that it cannot be a string, while accepting any zval =
numeric value. This is a little harder because it should be implemented =
as an alias of 'int!|float!', and we wanted to reserve union types for a =
future release.

About using zval type *and* value, I don't like it too, and I would =
prefer using types only, but I see no way of keeping accepting "31" as =
int without depending of the runtime value. Additional strict types, as =
proposed above, may be a partial solution because those would never care =
about value.

However, the more I think about it, the more I think that this set of =
strict types will be necessary to design union types, as defining a set =
of rules to convert a zval to a union of weak types, while possible, =
will be a mess. So, future union types could be strict-only, which will =
make them suitable for analysis.

I'm afraid this is probably not what you expect but, as I previously =
said, I'm trying to satisfy as many people as possible. Maybe you're =
right and '0.3 or nothing' proponents are a 'crowd', but I am not doing =
politics. If this is the case, the 'crowd' will win and this will be =
perfect.

Now, if you want to collaborate on the compromise we are trying to =
build, I really value your opinion. I don't pretend to be right in any =
way and I understand your pov but, if you stay on '0.3 or nothing', I =
cannot do much more.

Regards

Fran=C3=A7ois