(Sorry Andrea, I'm picking on your e-mail because it's easiest, but
it's a general response to the thread.)
On 13 October 2015 at 06:32, Andrea Faulds <a...@ajf.me> wrote:
> e.g.
>
> $ ./sapi/cli/php -r 'function foo(): long {}'
>
> Fatal error: 'long' is not a valid type hint, use 'int' instead in
> Command line code on line 1
>
> This would completely solve the confusion issue, I think. A crystal clear
> error message.
It is a good error message, but I disagree with the premise behind it:
> As I've said in a different email, I don't like the idea of allowing the
> aliases because it'd be another set of coding style differences we don't
> need. This lets us pick one name and stick with it, without causing
> confusion.
I agree that we should do something, but I think we should alias.
We allow both "int" and "integer" in settype() and we allow it in type
casting — the two other places where a user can specify a type for
conversion. I still think it's a poor choice to not allow both in type
declarations: while I'm generally a fan of having one way to do
things, I believe that the inconsistency in the language is worse than
the potential ambiguity in style guides.
Hell, _I_ still can't remember which out of "int" and "integer" is the
right one, and I've now written a decent amount of PHP 7 code _and_
wrote half of the documentation for this.
Plus, if we error when "integer" is used, we've moved people's cheese
anyway (by disallowing the class name). Let's not compound that by
forcing them to do busywork.
Adam, who hopes that anecdote doesn't say more about his working
memory than the design of the language.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
