On Wed, Dec 10, 2014 at 10:59 AM, Andrea Faulds <[email protected]> wrote:
>> On 10 Dec 2014, at 18:55, Sara Golemon <[email protected]> wrote:
>> I was just updating my HHVM patch to match your PHP implementation and
>> an issue came up. The following code, which is valid in PHP5:
>>
>> <?php
>> echo json_decode("\"ma\u00F1ana\"");
>>
>> Will throw a fatal compiler error as "\u00F1" is an invalid unicode
>> escape sequence. Since this represents an unnecessary BC break, I'd
>> like to propose the error handling be modified to match \x, which is
>> to say: Pass the value through unmodified.
>
> I was wondering about that case. Previously, the patch just raised a warning
> but let it through unmodified. But then old code would be littered with
> warnings,
> and I felt it was better just to throw an error. Part of the problem is that
> I’d rather
> mistakes in string literals be caught at compile time, to prevent someone
> accidentally echoing ‘\u00F1’ somewhere.
>
Well, consistency would be not raising a warning at all (like with \x
or unknown \ sequences), but I get your concern with helping coders
catch mistakes early.
I don't have the stats on how many projects are using \uXXXX sequences
(with the json_decode() or similar hack to parse them), but I know
FB's codebase is absolutely covered in them.
> A possible compromise might be to let ‘\u’ through but not ‘\u{‘.
>
Still don't like it from the inconsistency with existing escape
sequence handlers pov, but it'd cover the biggest set of BC issues, so
I'd be happy with it.
-Sara
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
