Hi François,
> Instead of rejecting the whole RFC, you can ask to keep supporting leading
> and trailing blanks in numeric strings. That's something that is really
> still under discussion, even between authors. To be clear, I prefer
> authorizing leading and trailing blanks (but just blanks), Zeev prefers
> restricting it, and I am not sure about Dmitry's preference. So you see it
> is still open !
I can definitely understand the indecision here! On the one hand, supporting
leading/trailing spaces usually works great when working with user input (and
many applications depend on this). On the other hand, it can lead to bugs
in sensitive code (e.g. for authentication, finance, or cryptography). This
is where the dual-mode RFC has a clear advantage, in my view. Its default
weak mode doesn't break BC and "just works" for user input, and developers
can optionally enable strict mode for a file when needed.
> About BC, I don't think we are too lax with BC because developers would have
> years to fix a pair of lines in their code. Running wordpress and other
> large code just found 10 or 20 places where developers would have to change
> something. So that's really minimal work and they have long years to do it.
The work to properly trim and validate input is not necessarily minimal,
unless developers add explicit casts wherever input is passed to a function
expecting a integer or float (in which case the advantage of the stricter
rules is lost). From my own experience working with legacy codebases, I
think you are underestimating the amount of work required to avoid errors
caused by a change to PHP's default casting behavior.
> Our STH does not break anything. Maybe the newly-published version is more
> clear. We propose implementing *exactly* the PHP5 logic and just raise
> E_DEPRECATED messages that won't stop execution at all. Ignoring these
> messages, there will be absolutely no difference in behavior with PHP 5.
I understand the two-staged migration proposed in the RFC. It most certainly
will break things in a future version. Essentially the coercive proposal
forces developers to update large amounts of legacy code dependent on PHP's
existing, well-documented behavior.
> Maybe not clear in the RFC but return types are handled exactly the same
> way.
Thanks for clarifying. I think this behavior should be mentioned in the
coercive RFC along with usage examples.
>> Strict types + static analysis can tell you that this will fail (because it's
>> based purely on types, and a string is being passed to a function expecting
>> an integer). Coercive typing cannot statically tell you that it will fail,
>> because it doesn't know whether the string passed to `getInvoiceByCustomer`
>> is acceptable as an integer without also knowing its value.
>
> Agreed. That's why, in the future, we may add new 'strict' type hint that
> will accept nothing but their native type. We didn't add them here because
> it would have been too confusing for a first release, and the whole
> discussion is already complex enough. But I agree they can have some use.
...
> If strict type hints are defined in the future, and if you use them in your
> example, you will get exactly the same and static analysis will still be
> able to find your bug. The difference is that you will decide to use them
> only where you need to make it more strict, function by function, argument
> by argument.
It sounds like you recognize the benefits of an optional strict mode. But
implementing this via separate 'strict' type hints would be far worse than
the per-file declare switch, in my opinion. Rather than only needing to think
about function calls and returns *in the current file,* a user would have to
think about which kind of type hint is used on individual functions and even
individual arguments in every other file or library they want to use. Moreover,
libraries would not be able to add these strict hints without breaking BC.
Why wait for a disparate strict mode in a future version of PHP, when there
is already a practical proposal on the table which can make it into PHP 7?
Best regards,
Theodore Brown
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
