Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82929
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 74.125.82.47 as permitted sender)
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (1.0)
In-Reply-To: <CAESVnVpA+M6iv_zbDmKTEF8Q1zKjwnbi1ucc=UyuUyRr+X+U3w@mail.gmail.com>
Date: Tue, 17 Feb 2015 08:34:32 +0200
Cc: "francois@php.net" <francois@php.net>,
 PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <C00D951D-7D49-4301-B8C6-6AE7338B4D11@zend.com>
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>
To: Sara Golemon <pollita@php.net>
Subject: Re: [PHP-DEV] Reviving scalar type hints
From: zeev@zend.com (Zeev Suraski)

In a word, yes.  Have to say you're abilities to compile Zeev -> formal decl=
aration are pretty amazing :)

Zeev

> On 17 =D7=91=D7=A4=D7=91=D7=A8=D7=B3 2015, at 08:20, Sara Golemon <pollita=
@php.net> wrote:
>=20
>> On Mon, Feb 16, 2015 at 10:04 PM, Zeev Suraski <zeev@zend.com> wrote:
>> That syntax poll aside, I had what I hope is some sort an enlightenment, a=
nd
>> I think I know what will get me to cast my vote in favor of 'strict', as a=

>> true supporter.  There's one very special conversion that's too common in=

>> PHP to dismiss (IMHO), and is also completely harmless in 99.999% of the
>> cases, if not strictly 100%:
>>=20
>> string->int or string->float conversions, when the string looks *exactly*=

>> like a number.  Given almost all of our inputs (from databases, forms,
>> files, etc.) come in string form, that's by far the conversion that's goi=
ng
>> to give us the most trouble - and is most probably the use case that by f=
ar
>> is going to result the largest amount of explicit casts to work around th=
at
>> problem.
>>=20
>> What if strict mode didn't just blindly check zval.type, but actually
>> allowed for this one type of conversion to go through without a problem?
>>=20
>> No bool to int.  No Apple to int.  No "123 testing" to float.  Just "32" t=
o
>> 32 and "37.7" to 37.7.
>>=20
>> Can the strict supporting camp consider that option?  Judging by the
>> examples brought up by proponents of v0.3, this type of conversion isn't
>> their issue.  It's the 'obviously wrong' conversions that bug them.
>>=20
>> As a secondary concern I'd put int to float conversions where no
>> (meaningful) data is being lost, e.g. 37 -> 37.0, even though a tiny bit o=
f
>> accuracy is lost.  Rejecting this particular conversion places us at bein=
g
>> stricter than mostly all other languages.  That said, it's a much less
>> common conversion so I don't feel nearly as strongly about it as the stri=
ng
>> one.
>>=20
>> Last, regarding internal functions, I do agree with Rasmus and Drew.  Aga=
in,
>> judging by the examples brought up  as a part of the discussion, it seems=
 as
>> if we gave ZPP developers a standard easy way of being a lot more picky
>> about the types of values of particular arguments, and allowing them to d=
o
>> this selectively for those places that are very sensitive (e.g.
>> curl_setopt()) would be a more suitable solution than just turning strict=

>> validation for all internal functions, which were built with very very
>> different assumptions in mind.  The biggest difference between internal
>> functions and userland functions in the context of this RFC is that with
>> userland functions, we're starting with a clean slate.  There are no type=

>> hint definitions anywhere, developers can selectively add them as they se=
e
>> fit.  With internal functions, we have type requirements EVERYWHERE alrea=
dy,
>> but with semantics that didn't take strict typing into account at all and=

>> evolved for almost 20 years.  Strict typing the way it is now would
>> radically change these semantics overnight, and will make the adoption of=

>> strict a much bigger headache than it can be, as I believe Rasmus
>> demonstrated.
>>=20
>> I think addressing these issues could get us a LOT closer to consensus an=
d
>> make a lot of those who voted 'no' on v0.3 vote yes  on v0.4.
> So, if you'll permit me to summarize your message.  The following
> would be palatable to you?
>=20
> * Lossless coercion.  This would sit somewhere between strict types
> and weak types as lossy conversions (object->__toString() for objects
> passed where string expected, any->bool) would be disallowed, but
> lossless conversions (numeric strings to number types, int to float,
> whole floats to ints, numbers to strings -- But no implicit
> conversions to bools, no non-numeric strings to numerics, etc...)
>=20
> * Exclude internal functions from the strict switch. (Perhaps have a
> separate switch for internal functions at a later date)
>=20
> With option to introduce features such as the following at a later date:
>=20
> * Union types (e.g. function foo((int | float) $value): (bool | string) { .=
.. })
> * Typedefs (e.g. TypeDef (int|float) numeric; -- Some defined as
> standard (like numeric), others user-definable)
>=20
> -Sara