Hey Sara,
Sara Golemon wrote:
On Fri, Oct 2, 2015 at 6:53 AM, Bishop Bettini <bis...@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/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
