Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80136
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <93B11897-3B8E-4D71-A8EB-A2D67B5446E9@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>
	<CAOjCV8wshLQJYqRPXS7wEodwhkMK-_W0qvxzNMe1F=SYe8svmA@mail.gmail.com>
	<93B11897-3B8E-4D71-A8EB-A2D67B5446E9@ajf.me>
Date: Sat, 3 Jan 2015 19:43:25 -0800
Message-ID: <CAEZPtU6YoDNf1uRxebAbQ=bceSL-GNa0ow+kJTiAx4vyOA6C+g@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>
Cc: PHP internals <internals@lists.php.net>, 
	"Sebastian B.-Hagensen" <sbj.ml.read@gmail.com>
Content-Type: multipart/alternative; boundary=001a11397ec04caefd050bcb609b
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hints
From: pierre.php@gmail.com (Pierre Joye)

--001a11397ec04caefd050bcb609b
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

On Jan 4, 2015 3:10 AM, "Andrea Faulds" <ajf@ajf.me> wrote:
>
> Hi Sebastian,
>
> > On 3 Jan 2015, at 19:46, Sebastian B.-Hagensen <sbj.ml.read@gmail.com>
wrote:
> >>
> >> Yeah, I don=E2=80=99t like this behaviour much. I want to avoid incons=
istency
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.
>
> That would be the idea.
>
> > After skimming through the RFC I'm unsure what the following code would
produce:
> >
> > 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 :
>
> The first argument would be converted to 10 and a notice (=E2=80=9CNon we=
ll
formed numeric string=E2=80=9D). The second would also be converted to 10, =
but
silently.

Hm. It sounds bad. There is a data loss, a notice must be raised. This is
exactly the kind of magic conversion that should not happen for arguments.

> I agree with your sentiments about data loss, but I am reluctant to
deviate much from the behaviour of internal functions to avoid the
inconsistency that plagued the previous RFC.

Right, but this is what I would expect. Am I the only one?

--001a11397ec04caefd050bcb609b--