Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82957
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.213.177 as permitted sender)
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>
In-Reply-To: <022801d04ab1$4a0c47d0$de24d770$@php.net>
MIME-Version: 1.0
Thread-index: AQGD0sLDaA+/0NIeBlQhQC5OtPA/xwHih9+6AanvcsEBj7eMCwEU0CpMAs0H7+gBDwGZj509VtRw
Date: Tue, 17 Feb 2015 15:33:52 +0200
Message-ID: <1913e09d7f52541901d8574d2080a63f@mail.gmail.com>
To: francois@php.net, Sara Golemon <pollita@php.net>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: RE: [PHP-DEV] Reviving scalar type hints
From: zeev@zend.com (Zeev Suraski)

> -----Original Message-----
> From: Fran=C3=A7ois Laupretre [mailto:francois@php.net]
> Sent: Tuesday, February 17, 2015 2:58 PM
> To: 'Sara Golemon'; 'Zeev Suraski'
> Cc: 'PHP internals'
> Subject: RE: [PHP-DEV] Reviving scalar type hints
>
> 2. It is not not about being lossless or not. People expect bool -> int t=
o
> be
> disabled, for example, and it is not lossless.
>
> 3. It is more a question of finding a consensus about conversions which
> don't
> make sense, and disabling them. Examples include bool conversion to any
> other type and, of course, disabling trailing chars in numeric strings.

I agree.  It's more of a question of eliminating potentially dangerous
conversions than just being lossless.

> 4. Once this is done, 99% of strict type proponents already said they
> would
> be OK with the so-called (not so) weak mode, making it possible to get ri=
d
> of
> this far from perfect two-mode mechanism (actually, this two-mode
> approach more and more reminds me a great idea about bringing
> transparent Unicode support in PHP).

Even though that's not what I meant when I sent my proposal in the morning,
I've been wondering about the same thing (also with the feedback from
Dmitry).  Can go an extra step from both directions, and come up with a rul=
e
set that is stricter than the currently proposed weak hinting, but not as
strict as the currently proposed strict hinting?
Key challenge I see with that is that scalar type hinting would go farther
apart from our implicit casting rules.  However, the current RFC already
aligned with ZPP as opposed to implicit casting rules (e.g. by rejecting
"Apple" as an int).  Choosing between that and having two separate modes, I
think that's the better option.

> > * Exclude internal functions from the strict switch. (Perhaps have a
> > separate switch for internal functions at a later date)
>
> This would make the feature inconsistent from an end user's pov.
>
> If a user enables strict mode, he assumes strict checks for every functio=
n
> he
> calls. *We* know that userspace and internal functions use different
> mechanisms, but the end user doesn't have to know. From his pov, a
> function
> is a function.

I think that practically speaking, that is incorrect, at least from my
experience with PHP developers.  They do differentiate between built-in
functions and userland functions.  There are some fundamental differences
between the two (being able to find their code, step into them in a
debugger, find docs on php.net, etc.).
As I mentioned earlier, the fundamental difference between built-in
functions and userland functions in the context of our discussion is that i=
f
we introduce userland type hints, nothing happens before people change thei=
r
code, and make (hopefully) informed decisions about what type hints to add,
if any.  No such luck with built-in functions, which have type information
associated, built collectively over the last two decades.  As Rasmus
demonstrated, flipping that switch on for built-in functions results in a
lot of work to 'clean' the code up, but you end up with having code that's
not necessarily any better.  That said, it's quite possible that the
situation will be much improved if & when we implement the less-strict rule=
s
we're proposing here, which would accept "32" as an integer or 37 as a
float.

If we still see that employing the strict(er) rules is very noisy with
internal functions, a more appropriate option may be introducing new types
into ZPP, that would correspond to the new rules we introduce in the
userland type hints, and requiring extension authors to explicitly move to
them where they believe it's appropriate.  That will allow extension author=
s
to make their choice regarding their APIs, similarly to the process that
will happen in userland.


> So, from all these arguments, I now think that strict types, as defined i=
n
> 0.3,
> are not the best solution.
>
> > With option to introduce features such as the following at a later date=
:
> >
> > * 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)
>
> As I told Zeev, union types can be kept for the future if we don't go the
> nullable road, as it would be too confusing making 'string|null' and
> '?string'
> synonyms.

I think we all agree about that.

Zeev