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 <a...@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
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
