Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:75443
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.169 as permitted sender)
Message-ID: <53C3CFE6.90604@gmail.com>
Date: Mon, 14 Jul 2014 13:41:10 +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> <53C2C84A.6060308@garfieldtech.com> <49C63232-AB78-4B2C-A3E4-B21748D5D489@ajf.me> <53C2DC03.2050609@gmail.com> <CAL0xaBHa6uYZjn9K-pYr8=ovygX8mToCxfKxqBhrvVvZCjNTNQ@mail.gmail.com>
In-Reply-To: <CAL0xaBHa6uYZjn9K-pYr8=ovygX8mToCxfKxqBhrvVvZCjNTNQ@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)

Arvids Godjuks wrote (on 14/07/2014):
> We already have quite good implementation for the array and object hints,
> they do their job and do it good. No need to change those at all - leave
> them as is - no need to add magic with casts and all that. Function/method
> requires an array? Make casts explicitly and pass it an array and not an
> integer.

Yes, I totally agree. What I don't think makes sense is for the keyword 
"array" in a function signature to mean "error if a string is passed", 
but the keyword "int" in exactly the same place to mean "happily accept 
any string (or even an array) and cast it to int, even if it's a lossy 
conversion".

If there is to be a short-hand for casts in function signatures, it 
should not reuse the current syntax for type assertions, as they are not 
equivalent facilities.

> But this automatic
> casting should work only between string, integer, float, bool and null
> types and only between these. No automatic casting of these 5 to arrays or
> objects.

Rather than special-casing this for "static types" (despite the fact 
that arrays *can* be cast from other types) I would prefer to see it 
only happen where it can be *lossless* (which is never the case for 
arrays, thus making the current logic consistent with the new rule). 
This is essentially what the current RFC proposes.

I don't think that's actually overthinking it any more than the scalar 
vs non-scalar version would, as it's a pretty easy rule to express. 
Broadly, if (source_type)(target_type)$var == $var, that's a lossless 
cast. (There are a couple of odd exceptions with very specific values, 
such as (int)(array)1 == 1, but it's not too much of a stretch to say 
"all array casts are considered lossy".)

> You just need to get a warning, that you can disable via
> error_reporting, and just make your prototype with all the type hints you
> need and deal with the cast warnings in the type hints later on.

As I've said elsewhere, I see the usefulness of emitting warnings of 
some kind for "lossy" casts as a separate question from the usefulness 
of performing such casts inline in function signatures. It makes sense 
for the language to implement both at once, but for the user to be able 
to use them separately (e.g. catch lossy conversion in existing uses of 
(int)$foo).

Regards,
-- 
Rowan Collins
[IMSoP]