Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:75431
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.41 as permitted sender)
Message-ID: <53C2BB17.4030202@gmail.com>
Date: Sun, 13 Jul 2014 18:00:07 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: internals@lists.php.net
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> <93bb0c689ccca03a0af46c51abf0e11f@mail.gmail.com>
In-Reply-To: <93bb0c689ccca03a0af46c51abf0e11f@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
From: rowan.collins@gmail.com (Rowan Collins)

On 13/07/2014 17:28, Zeev Suraski wrote:
> BTW, auto-converting type hints were
> proposed by Lukas and me back in 2010, even though I see them attributed to
> Anthony in 2012 :)

Aha, seems like a case of convergent thinking, with the exception that 
Anthony proposed using distinct syntax to represent the casts (the wiki 
isn't rendering properly for me, so apologies if that is also covered in 
your older proposal).

As I've mentioned elsewhere, having the same syntax mean "assert" for 
scalars but "cast" for non-scalars leads to an ambiguity with arrays, 
for which both actions are available (and current code performs an 
assertion).

>> 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).

I think a lot of this hinges on the next question, of whether the 
warning semantics are inherently tied to this new syntax, or a separate 
issue.

To me, it makes perfect sense for the following to be equivalent, with 
one just a more expressive way of writing it:

function casts_as_array($foo) { $foo = (array)$foo; /* ... */ }
function casts_as_array((array)$foo) { /* ... */ }


>
>> 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.

Other than isolating the change for backwards compatibility, I don't see 
a big reason to treat them as separate. If the aim is to make the scalar 
type hints "just like an existing cast", then lossy casts should work 
the same way in both places.

On the other hand, if the aim is to make it easier to detect lossy 
casts, then a way to do that *outside* function signatures is just as 
useful as a way embedded in them.

In fact, thinking about it, several of these proposals add implicit 
functionality in the function signature which would remain tricky in 
userland code. Current type-hinting does not do this (it can be emulated 
fairly easily with is_array(), is_callable(), and instanceof).

If we don't want all casts to emit warnings on loss, perhaps a new 
function or keyword request them - e.g. (strict int)$foo, or 
strict_cast($foo, 'int').

Regards,

-- 
Rowan Collins
[IMSoP]