Re: [DRAFT][RFC] Big Integer Support
| From: | Andrea Faulds | Date: | Mon, 07 Jul 2014 00:52:51 +0000 |
| Subject: | Re: [DRAFT][RFC] Big Integer Support | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-75296@lists.php.net to get a copy of this message | ||
On 3 Jul 2014, at 18:29, Andrea Faulds <ajf@ajf.me> wrote:
> Either way, I think there should be some sort of warning (probably an E_NOTICE
> or E_WARNING?) when this cast happens implicitly and the number is truncated,
> such as in function calls. I’m tempted to remove this from Open Questions and
> instead just Do The Right Thing and if someone objects later, the patch and RFC
> can always be changed.
>
> Of course, it’s worth noting we currently *don’t* do any sort of warning when
> casting a float to a long causes a loss of information. Anthony Ferrara’s sadly
> withdrawn RFC for scalar type hints would have done this for user land
> functions, but that hasn’t happened yet, so adding a warning here would be
> inconsistent with floats.
The patch now raises an E_RECOVERABLE_ERROR if a bigint that is too large is passed as an argument
to a function expecting a long. I think this is best as it would hopefully prevent bugs. I was
inspired by Anthony Ferrara’s scalar type hinting RFC and Python’s OverflowErrors here.
However, this does cause the previously mentioned issue that floats don’t do the same thing and
simply truncate without warning here. Should we change the behaviour for them as well? It would be
inconsistent not to. Should I make a separate RFC which would make number casting behaviour strict
and then make the bigint patch and RFC consistent with it, on the hope that separate RFC could be
passed first? That way this wouldn’t become an issue that might block the bigint RFC.
--
Andrea Faulds
http://ajf.me/