Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83079
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.223.172 as permitted sender)
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>	<CAPhkiZxvJda-Q1WEr7LTrX9BCHKs0QapQ8f=hh8L+1SNC+KFHQ@mail.gmail.com>
 <CALwr1G=wEYNLegXrNerPk0Yp2AW5cPhdkzWUaD4ik_RrCPw6Gg@mail.gmail.com>
In-Reply-To: <CALwr1G=wEYNLegXrNerPk0Yp2AW5cPhdkzWUaD4ik_RrCPw6Gg@mail.gmail.com>
MIME-Version: 1.0
Thread-Index: AQKz6wpj8b81mnwJq1LfxWbU4ZJyQgGjcksIAbrU1N8Bn0wufQGLyLi6AmixSwcCoM80eprSqDwQ
Date: Wed, 18 Feb 2015 17:10:57 +0200
Message-ID: <da4521df7fa54cf0f3059f07a3450b42@mail.gmail.com>
To: =?UTF-8?Q?P=C3=A1draic_Brady?= <padraic.brady@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: RE: [PHP-DEV] Scalar Type Hints v0.4
From: zeev@zend.com (Zeev Suraski)

> -----Original Message-----
> From: P=C3=A1draic Brady [mailto:padraic.brady@gmail.com]
> Sent: Wednesday, February 18, 2015 4:50 PM
> To: Andrey Andreev
> Cc: Zeev Suraski; Nikita Popov; Rasmus Lerdorf; Sara Golemon; PHP
> internals
> Subject: Re: [PHP-DEV] Scalar Type Hints v0.4
>
> Hi all,
>
> On 18 February 2015 at 09:14, Andrey Andreev <narf@devilix.net> wrote:
> > Hi,
> >
> > On Wed, Feb 18, 2015 at 9:00 AM, Zeev Suraski <zeev@zend.com> wrote:
> >> 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?
> >>
> >
> > I too am curious about the potential issue with "123" to 123
> > specifically, although it could be seen as a subset of another problem
> > that is solved with strict hints - numeric-character string
> > identifiers being erroneously treated as integers.
>
> However, =E2=80=9C123=E2=80=9D is exceptional. It=E2=80=99s redefining an=
 integer as =E2=80=9C an integer
> or a
> string comprised wholly of digits without leading zeroes, with an optiona=
l
> leading hyphen, and representing an integer up to PHP_INT_MAX=E2=80=9D, i=
.e. an
> integer or a string with a real number that be made an integer without
> loss.
> No other string need apply. That=E2=80=99s not strict-strict typing (ther=
e=E2=80=99s
> coercion)
> but it=E2=80=99s probably strict enough to pass muster (it=E2=80=99s one =
single obvious
> coercion under limited circumstances).

> Then again, it=E2=80=99s an exception that requires a long sentence.

There are shorter ways to define this exception - not in a formal way
perhaps, but that gets the point across - something like 'a string that
looks like an integer', and we can throw in 'and that can be converted with
no data loss'.  Of course, writing docs isn't one of my strong points :)

> It=E2=80=99s just not clear,
> to me, if this is the sole intended exception, or if that sentence needs
> to be
> expanded to a paragraph. A section? Are we going to need a chapter? I=E2=
=80=99m
> assuming octals-in-a-string are a no-go to be coerced whereas others migh=
t
> just see an integer with superfluous leading zeroes.

It's not the sole exception, but it's one of the most important one in my
opinion.  The rationale would be conversions that can be made without
meaningful data loss or creating data that wasn't there.

That means that "42" can coerce into int, and "42.2" can coerce into float,
and int can coerce into float - but not vice versa.
That means that boolean will not coerce into anything, because turning it
into an integer, float or string 'invents' data that wasn't there.
A somewhat sticky points is coercion into boolean.  We need to figure this
one out, and hopefully we can come up with something most people can agree
to.
Another open question would be coercion of float/int into string.  This
particular point might be good for a secondary vote, as I imagine people
from both camps won't see this particular conversion as a major deal-breake=
r
for them (could be wrong).

Getting the point across could be made using a table very similar to the on=
e
in wiki.php.net/rfc/scalar_type_hints#behaviour_of_weak_type_checks (as you
seemed to suggest) - of course modified to reflect the much stricter rulese=
t
we're talking about here.  I don't imagine that even a formal declaration
would require a whole chapter.

Thanks!

Zeev