Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:75459
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.178 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <53C3CFE6.90604@gmail.com>
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>
 <53C3CFE6.90604@gmail.com>
Date: Mon, 14 Jul 2014 16:40:38 +0300
Message-ID: <CAL0xaBFMBzd4FadjufRAJGXUTw7hij2VT1J6ndzBo3xzPp-diw@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c1566ae8575b04fe2770ea
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
From: arvids.godjuks@gmail.com (Arvids Godjuks)

--001a11c1566ae8575b04fe2770ea
Content-Type: text/plain; charset=UTF-8

2014-07-14 15:41 GMT+03:00 Rowan Collins <rowan.collins@gmail.com>:

> 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".)


There is no special casing, Array and Object type hints are already
implemented and are in the language for quite a long time. Just don't touch
them, that's all I ask. Implement scalar hints and because of the nature of
PHP - they need to have type casting built in. Otherwise you are forced to
typecast on your own everything that comes from the outside sources:
GET/POST/Databases/API's/REST/the whole lot. If it was a correct string
that was converted to an int/float without any data loss - keep calm and
carry on.

--001a11c1566ae8575b04fe2770ea--