Re: Strings, invalid escape sequences and parse errors

Hey Sara, Sara Golemon wrote:

On Fri, Oct 2, 2015 at 6:53 AM, Bishop Bettini <bishop@php.net> wrote:

Option (b) sounds reasonable, but there's probably A Solid Reason it was implemented that way

AIUI, the "solid reason" was because it's dangerous to fail silently where you have high confidence that something is wrong. Again, I believe in it, but the arguments against option A illustrate why it might not be practical. I hate to say this, but in the interest of consistency (were 7.0 not in its final stage) I'd vote for B.

I made \u work the way it does because I don't like repeating the mistakes of the past. It deliberately uses {} rather than a variable-length sequence of hex digits. Why? Because this way it's always completely clear where the boundary is between it and any following characters, unlike the mess which is octal and hex escapes. I also made it an error because, well, why shouldn't it be? People don't like it when something fails and you don't tell them. We don't even produce an E_NOTICE or E_STRICT or something for invalid escapes, we just pretend it's not an escape sequence. That's awful: it means code made for a PHP version which supports these escapes will silently break on other PHP versions. In \u's case, it would mean that if the Unicode standard extended or shrunk the range (U+0000–U+10FFFF) in future, we wouldn't be able to change \u's limits to match, because it would silently break PHP code. I'd love it if we could also make a slash followed by an unrecognised character always be an error, but alas, sounds like we can't do that. So for now, we can only make new escape sequences behave sensibly. \u is deliberately inconsistent. You can go replace it with \uXXXX if you really want to, but PHP's users will not thank you. Thanks. -- Andrea Faulds http://ajf.me/