On 23 Jul 2014, at 19:21, Robert Williams <rewilli...@thesba.com> wrote:

> It seems odd to me to not support the aliases. Since I can do this:
> 
>   $foo = (integer)$bar;
> 
> I would expect to be able to do this:
> 
>   function foo(integer $param) {}

Aliases mean inconsistency. We shouldn’t unnecessarily have multiple names for 
the same thing, just one. Also, for every alias we support, another reserved 
word is added. Hence we only allow one set of names. This is also Facebook’s 
approach with Hack, which removes the aliases entirely for type casting. I 
might propose we deprecate/remove the aliases in a future RFC.

> Also, do int, float, and numeric accept numbers in octal, hex, scientific 
> notation, etc.? I don’t believe there are any examples in the RFC that 
> intentionally or accidentally show what happens with, say, 0x2f as a value.

Ooh, you’ve caught me out there. The patch as it stands would permit such 
non-decimal numbers, which isn’t what it should do as convert_to_long_base_safe 
should actually permit only the specified base.

So, yes it does permit non-decimal numbers, but it’s a bug I need to fix.

--
Andrea Faulds
http://ajf.me/





--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to