Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81832
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain devilix.net designates 209.85.218.43 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <85CB3199-8D44-4D34-9212-6E18D6BD7B73@ajf.me>
References: <CA+9eiLuueVvYgT-fhCvzBSxzoDioinpc5Eok5OQtGDBG1FZM=w@mail.gmail.com>
	<CAPwsocFD6sUEzo6uE4X0N2OF_N_eze5k+=f7Z+WyZHum7=MoeA@mail.gmail.com>
	<CABRjmp9a-ZfqWv3B4xh70LUEGFP4RpXgNwwYkRmnq9ST0y7CuQ@mail.gmail.com>
	<CAPhkiZy+q0wMyEHXPbWW+V-W+sLKHV9jKehggw-pS-j+PEXrPw@mail.gmail.com>
	<85CB3199-8D44-4D34-9212-6E18D6BD7B73@ajf.me>
Date: Wed, 4 Feb 2015 20:41:18 +0200
Message-ID: <CAPhkiZy6jfhH9aNv72+rysWMDhzo3y0qvKED6goRi0eF8vmyJg@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>
Cc: Florian Margaine <florian@margaine.com>, Leigh <leight@gmail.com>, 
	PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] What do we need strict scalar type hints for?
From: narf@devilix.net (Andrey Andreev)

Hi Andrea,

On Wed, Feb 4, 2015 at 8:21 PM, Andrea Faulds <ajf@ajf.me> wrote:
> Hi again,
>
>> On 4 Feb 2015, at 11:15, Andrey Andreev <narf@devilix.net> wrote:
>>
>> On Wed, Feb 4, 2015 at 1:02 PM, Florian Margaine <florian@margaine.com> =
wrote:
>>> Hi Leigh,
>>>
>>> Le 4 f=C3=A9vr. 2015 11:50, "Leigh" <leight@gmail.com> a =C3=A9crit :
>>>>
>>>> What was wrong with:
>>>>
>>>> function x(int $y, string $z) { // strict
>>>> function x((int) $y, (string) $z) { // casting
>>>>
>>>> This was the best suggestion I've seen that covers the requirements of
>>>> both camps, and is still very clear how data is going to be handled.
>>>>
>>>> Authors who want their APIs to adhered to strictly can do that,
>>>> authors who want to accept anything and have it end up as their
>>>> desired type can do that too.
>>>
>>> Because it is then the callee who decides, not the caller, whether or n=
ot
>>> he wants strict typing.
>>>
>>
>> ... and apparently, this is the root of all evil. :)
>
> It=E2=80=99s not =E2=80=9Cthe root of all evil". But the two-syntax appro=
ach has disadvantages I=E2=80=99ve elaborated numerous times.
>
> It shifts the choice to the callee, not the caller. This means existing a=
pplications are broken if strict hints are added to existing libraries. It =
means that programmers will have to deal with two different systems, simult=
aneously, in the same file or function or method, because one API uses (int=
) and the other uses int. It means that if the API author decides to have w=
eak types, you are prevented by the language from having the benefits of st=
rict typing, even if you want them. It also has a syntax issue: (int) looks=
 like an explicit cast, yet what is usually proposed doesn=E2=80=99t someth=
ing similar. There=E2=80=99s also the consistency issue in that we=E2=80=99=
d have to support real for consistency with (real), since T_DOUBLE_CAST is =
a token. It means that internal functions could now also use strict hints -=
 or if they can=E2=80=99t, we have a consistency issue. It means beginners,=
 and people who don=E2=80=99t like strict types, now have to deal with stri=
ct types in their code, despite PHP always having been a weakly-typed, begi=
nner-friendly language. And so on, and so forth.
>
> The current RFC deliberately does not propose this because I think it cau=
ses more problems then it solves.
>
>> I am baffled by how the two-syntaxes suggestion is always so easily
>> dismissed by that argument. I'd argue that most people who support the
>> current proposal don't fully understand what declare(strict_type=3D1)
>> really does.
>
> Well, *I* understand what it does.

That's an own goal (in football/soccer terms), you know. ;)

> I=E2=80=99ve used it. It worked really, fantastically well=E2=80=A6 bette=
r than I expected it to. It provided benefits that the two-syntax suggestio=
n wouldn=E2=80=99t have. It provided benefits that just strict hints wouldn=
=E2=80=99t have. It provided benefits that just weak hints wouldn=E2=80=99t=
 have.
>
>> As I've previously said - putting the caller in control
>> (and really the caller, not in a per-file context) makes it a
>> debugging tool, not support for strict typing.
>
> What=E2=80=99s the difference between =E2=80=9Cper-file=E2=80=9D and =E2=
=80=9Creally the caller=E2=80=9D? The RFC *does* allow you to use declare()=
 blocks if you really want to.
>
> Also, type hints are mostly a debugging tool anyway. They=E2=80=99re a to=
ol for catching errors early, and to enable better documentation. That=E2=
=80=99s all that they do.
>

Yeah, you've said that numerous times ... almost as much as I have
disagreed with your arguments.

I didn't want to turn this thread into a re-iteration of the RFC
discussion one. I'm just completely surprised how relentlessly all
suggestions about two syntaxes have been waved off by a callee vs
caller argument like it's a golden rule or something ... it's not, you
just don't like the other approach.

Cheers,
Andrey.