Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80057
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain thomasbley.de from 85.13.137.24 cause and error)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
User-Agent: ALL-INKL Webmail 2.11
In-Reply-To: <CAF+90c-uiLj1QoT+dXfd1obRXNcYcpBAJ-aU59yEXk+HYNZRFw@mail.gmail.com>
References: <41D5BB0B-73AF-488E-968D-90B2878E3178@ajf.me><CAF+90c-uiLj1QoT+dXfd1obRXNcYcpBAJ-aU59yEXk+HYNZRFw@mail.gmail.com>
To: ajf@ajf.me, nikita.ppv@gmail.com
Cc: internals@lists.php.net
Message-ID: <20150101164402.EB1442605AB@dd15934.kasserver.com>
Date: Thu,  1 Jan 2015 17:44:02 +0100 (CET)
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hints
From: mails@thomasbley.de ("Thomas Bley")

I think it is no problem to add strict parameter type hints with another rfc (if this rfc gets accepted), e.g. function foobar(string! $str, int! $str){} or any other syntax.

Regards
Thomas

Nikita Popov wrote on 01.01.2015 15:05:

> On Wed, Dec 31, 2014 at 9:27 PM, Andrea Faulds <ajf@ajf.me> wrote:
> 
>> Good evening,
>>
>> Parameter type hints for PHP’s scalar types are a long-requested feature
>> for PHP. Today I am proposing an RFC which is a new attempt to add them to
>> the language. It is my hope that we can finally get this done for PHP 7.
>>
>> I’d like to thank Dmitry, who emailed me and gave me some feedback on the
>> draft RFC and some improvements to the patch. He encouraged me to put this
>> to internals sooner rather than later, as it’s a feature many people 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
>