Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80045
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.180 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <41D5BB0B-73AF-488E-968D-90B2878E3178@ajf.me>
References: <41D5BB0B-73AF-488E-968D-90B2878E3178@ajf.me>
Date: Thu, 1 Jan 2015 15:05:13 +0100
Message-ID: <CAF+90c-uiLj1QoT+dXfd1obRXNcYcpBAJ-aU59yEXk+HYNZRFw@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7bdc807883656c050b97b661
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hints
From: nikita.ppv@gmail.com (Nikita Popov)

--047d7bdc807883656c050b97b661
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Dec 31, 2014 at 9:27 PM, Andrea Faulds <ajf@ajf.me> wrote:

> Good evening,
>
> Parameter type hints for PHP=E2=80=99s scalar types are a long-requested =
feature
> for PHP. Today I am proposing an RFC which is a new attempt to add them t=
o
> the language. It is my hope that we can finally get this done for PHP 7.
>
> I=E2=80=99d like to thank Dmitry, who emailed me and gave me some feedbac=
k on the
> draft RFC and some improvements to the patch. He encouraged me to put thi=
s
> to internals sooner rather than later, as it=E2=80=99s a feature many peo=
ple are
> hoping will be in PHP 7.
>
> The new RFC can be found here: https://wiki.php.net/rfc/scalar_type_hints
>
> As well as the RFC, there is a working Zend Engine III patch with tests,
> and an incomplete specification patch.
>
> Please read the RFC (and specification patch, if you wish) and tell me
> your thoughts.
>
> Thanks!
>

While in favor of introducing scalar type annotations, I'm against this
proposal in particular. I've held a different position in the past, but by
now I'm thoroughly convinced that if we introduce scalar type declarations,
they should be strict. No wiggling, no casting.

Apart from being consistent with the existing behavior of type declarations
and being what the majority of the vocal community wants, it is also
possible to reason about strict type declarations statically.

This means that an IDE or other tool will be able to perform meaningful
analysis based on typehinted functions. E.g. if you pass the result of a
string function to an int parameter, your code is definitely wrong and you
can be told so. Loose typehints as proposed here do not offer this
possibility, because a string can be or can not be a valid input to an int
parameter depending on the exact value.

For the same reason loose typehints are also more fragile. Code that worked
in casual testing during development will fail in production when
unexpected, improperly validated user input is encountered. With strict
types on the other hand it is very likely that code working with one input
will also work with all other possible inputs, because the type check is
not value-dependent. (Types are typically much less volatile than values.)

The ability to statically check type annotations is rather important to me.
I think much of the usefulness of this feature would be lost without the
ability to check correct usage with tooling. I'd also like to point out
that Hack uses a strict type scheme and it seems to work well there (though
I do acknowledge that the situation is not the same, as Hack has a
generally more powerful and fully statically checked type system).

Apart from these general thoughts, I also think that this proposal is a
regression from the previous one. In the name of "consistency" it uses the
rather weak zpp validation rules, which allow a lot of questionable input.
Just look at the conversion table in the RFC, practically all of it is
"Yes". I understand the motivation to reduce the number of different
conversion semantics, but I just can't get behind it if it means reusing
existing, bad conversion rules.

Nikita

--047d7bdc807883656c050b97b661--