Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80122
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.173 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <360F9366-07C2-4C7A-AC3C-D482AFDD9838@ajf.me>
References: <41D5BB0B-73AF-488E-968D-90B2878E3178@ajf.me>
	<CAEZPtU79=VX1Scm6vVn-9iuHD=qqRoPMrsR4Ymqd9=QQeQbRCg@mail.gmail.com>
	<360F9366-07C2-4C7A-AC3C-D482AFDD9838@ajf.me>
Date: Sat, 3 Jan 2015 20:46:46 +0100
Message-ID: <CAOjCV8wshLQJYqRPXS7wEodwhkMK-_W0qvxzNMe1F=SYe8svmA@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>
Cc: Pierre Joye <pierre.php@gmail.com>, PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hints
From: sbj.ml.read@gmail.com ("Sebastian B.-Hagensen")

>> - on-numeric strings not accepted. Numeric strings with trailing
>> characters are accepted, but produce a notice.
>>
>> I would rather not allow fancy conversions here. Any trailing non
>> white spaces characters should not be allowed. I know it is not what
>> PHP does now in some cases but this is really a fuzzy area and never
>> really matched any actual needs or usages.
>
> Yeah, I don=E2=80=99t like this behaviour much. I want to avoid inconsist=
ency with the behaviour of extension functions (i.e. zend_parse_parameters)=
 where possible, though. Since this has come up so much, I should probably =
make an RFC to change this aspect of ZPP=E2=80=99s behaviour.

That RFC should probably be voted on before this RFC proceeds into voting.

After skimming through the RFC I'm unsure what the following code would pro=
duce:

function test(int $a, int $b) {}

test("10.4", 10.6);

If a warning/notice is raised, fine. If it will just result in $a =3D=3D=3D
(int)10 && $b =3D=3D=3D(int)10 :

I agree that consistency is a sound reason for this behavior. However
type annotations (or whatever they will be called) should not only
ensure that a parameter has a certain type but that no data was lost
during the conversion. It is reasonable (assuming the target type can
handle the value) and fine to convert an integer into a float,  a
float/integer to a string or any string that would satisfy is_numeric
into a float (or if no data was lost an integer) and hide it from the
developer (after all, that is was php is about). If a conversion might
result in data or precision loss the developer should be notified with
a hard failure. (E_RECOV, E_WARNING, I can still chose to ignore them
using error handlers or error_reporting settings).

Allowing data (I would also consider (string)'12a' =3D> int(12) data
loss) or precision loss while converting a typed parameter would
reduce the usability of the whole addition.

If I'm in a situation where data loss is acceptable I could just leave
the annotation away and cast as I would've always done or not cast and
trust on php to do whatever is required.
However caring about data loss in these specific occasions( including
the string -> int example above) would forbid me to use type
annotations. As I would have no way of knowing and bailing out if the
original value was altered before it was accessible by my code.

If type annotations wouldn't go beyond the safety that php currently
provides by converting in specific contexts and casting what is the
benefit in adding them?

However, while I see issues with the RFC (that might be related to a
misunderstanding on my side) I like the general direction.


>> I am also not a fan of errors, exception, at least for methods, make
>> much more sense. I know it is relatively easy to handle errors as
>> exception but still, let do it right now.
>
> That=E2=80=99s be inconsistent with our other type hints. To get this cha=
nged, I think we=E2=80=99ll just have to wait for Nikita=E2=80=99s Exceptio=
ns in the Engine for PHP 7 RFC.