Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88642
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.179 as permitted sender)
MIME-Version: 1.0
Reply-To: bishop@php.net
Sender: bishop.bettini@gmail.com
In-Reply-To: <CAPg3XxJSctvZL_DTdZtge+xoAbgeQjoMhYjndc107Jjk_KFO9g@mail.gmail.com>
References: <CAPg3XxJSctvZL_DTdZtge+xoAbgeQjoMhYjndc107Jjk_KFO9g@mail.gmail.com>
Date: Fri, 2 Oct 2015 09:53:53 -0400
Message-ID: <CAEYWF=5EdSQm+esdbCJE+D-kb50h_QhpOQ27B-JCxqXma-Yibw@mail.gmail.com>
To: Peter Cowburn <petercowburn@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7bb0405885181c05211f7e9d
Subject: Re: [PHP-DEV] Strings, invalid escape sequences and parse errors
From: bishop@php.net (Bishop Bettini)

--047d7bb0405885181c05211f7e9d
Content-Type: text/plain; charset=UTF-8

On Fri, Oct 2, 2015 at 4:18 AM, Peter Cowburn <petercowburn@gmail.com>
wrote:

> a) change all other "invalid" escape sequences to be a parse error [that
> would mean "\m" would raise a parse error!]
>
> b) change \u{} to behave like any other escape sequence, by not raising a
> parse error and instead keeping the literal characters
>
> or c) tell me to keep quiet and accept the oddball behaviour, having quirks
> is The PHP Way after all.
>

Well, I think option (a) would break parsed strings containing regex:

$subject = "there are words here";
$pattern = "/\w+/"; // problem
$rc = preg_match_all($pattern, $subject);
echo "Matches: \x1b[7m$rc\x1b[0m\n"; // not a problem

Option (b) sounds reasonable, but there's probably A Solid Reason it was
implemented that way, which if so leaves (c.ii): accepting the odd-ball
behavior....

--047d7bb0405885181c05211f7e9d--