Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:75427
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.220.179 as permitted sender)
References: <08503591-EFC8-48E6-984E-FFC292C5EA5F@ajf.me> <CAF+90c-ojALBgeyXu+f2tW6LoW8+4XGVpu_+i9SyX=u4RSoxug@mail.gmail.com>
 <027E65EF-C4FC-474C-92BB-D99EFADDEEED@ajf.me> <ada4093ad61814c182f8ca31939962ea@mail.gmail.com>
 <BDC11A4E-0610-49A3-B8AE-E9D3627B75C8@ajf.me> <eab1ceea2084415d21736a69c4ac6fdc@mail.gmail.com>
 <53C29EE4.3090808@gmail.com> <63e5b1c38d6e0c5111987e78d9b59be3@mail.gmail.com>
 <E2926DD2-B0AE-4A87-BEA8-F07FE49CE4B5@ajf.me> <b3026b451453e3c2412bbf45c59f5003@mail.gmail.com>
 <53C2AF35.40003@gmail.com>
In-Reply-To: <53C2AF35.40003@gmail.com>
MIME-Version: 1.0
Thread-Index: AQJuUFVOlGiX172RfpkkW7aXwqSXwwOWY2SKAql1dl4CVdDzGgKRSJF6AWT2/k4CFsPBuAJBAJoIAfHW5ZICVySzLAFmKj/jmawzh7A=
Date: Sun, 13 Jul 2014 19:28:40 +0300
Message-ID: <93bb0c689ccca03a0af46c51abf0e11f@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: internals@lists.php.net
Content-Type: text/plain; charset=UTF-8
Subject: RE: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
From: zeev@zend.com (Zeev Suraski)

> -----Original Message-----
> From: Rowan Collins [mailto:rowan.collins@gmail.com]
> Sent: Sunday, July 13, 2014 7:09 PM
> To: internals@lists.php.net
> Subject: Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
>
> On 13/07/2014 16:45, Zeev Suraski wrote:
> > Even reading Nikita's piece, he's saying he dislikes that option for
> > 'obvious reasons', but I see nothing obviously wrong with this approach.
> > [...] Unlike what's suggested in that piece, it's not equivalent at
> > all to docblocks, as it is in fact enforced, and as you said, has the
> > benefit of being able to write the 'inner code' without worrying about
> > the input types.
>
> I think you're muddling two sections of Nikita's article [1]. The option
> which is
> dismissed "for obvious reasons" is "unenforced type hinting" - keywords
> which do absolutely nothing other than give a literal hint to non-critical
> tools
> like documentation and reflection.

You're absolutely right.  My bad.  BTW, auto-converting type hints were
proposed by Lukas and me back in 2010, even though I see them attributed to
Anthony in 2012 :)

>
> The next section is about "casting weak type hinting", which is described
> as
> "one of the more interesting proposals". It certainly has merit, although
> in my
> opinion it's less powerful than the other options in what it adds to the
> language, as the equivalent userland boilerplate is really minimal (e.g.
> $foo =
> (int)$foo).

That's not a bad thing in my book - another way to describe it is that it's
consistent with the rest of the language and doesn't require developers to
learn another new set of 'similar, but different' semantics.

In terms of value that it does bring to the table, it gives you a standard
way to do something that's very common in a shorter way and increases
quality of APIs (it's much more likely people will use this to describe
their APIs than docblocks), and we can use better warning semantics than we
currently have on conversions (without changing the rules), and it allows
you to do all that without having to add tons of defensive code (in the
calling code) that is often unnecessary.  Making it easy to implement means
it'll get used more - and so far I fail to see what we stand to lose (more
on that below).

> As I've mentioned elsewhere, and indeed was mentioned in Anthony's
> proposal at the time [2], the addition of warnings on lossy casts is a
> completely
> separate issue to the ability to sugar those casts into a function
> signature.

I don't see why they would be separate, especially if the key reason for
going for 'option #3' is that it helps find bugs better.  Option #1 with the
added logic of warning about lost data or 'bogus' conversions has all the
advantages of option #3 but also other advantages.

> Now, what is being proposed here is effectively "casting strict type
> hinting", a
> variant of what Nikita called "strict weak type hinting", with the
> additional step
> of actually applying the lossless cast, rather than just asserting that
> it's
> possible. This actually provides a lot of functionality which is fiddly to
> implement in userland, and I can't see a lot of uses for asserting that a
> cast
> would be non-lossy, if you're not about to perform that cast (which is
> what
> "strict weak type hinting"
> allows).

Again, option #1 as I see it (and is mostly described in the 2010 RFC
https://wiki.php.net/rfc/typecheckingstrictandweak) - it's identical in
terms of rules to those of PHP's casting, but with warnings emitted for lost
data and 'bogus' conversions.  If we introduce this feature in a major
version, we could also consider change the casting code to emit these same
warnings so that we get full consistency - but that I think is in fact a
separate decision.

Zeev