Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:79161
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmx.de designates 212.227.15.19 as permitted sender)
Message-ID: <547469EF.4040404@gmx.de>
Date: Tue, 25 Nov 2014 12:37:19 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: ivan.enderlin@hoa-project.net, internals@lists.php.net
References: <C2A085AA-3E3A-405F-954B-4C1F68A46012@ajf.me> <54742FBD.802@hoa-project.net>
In-Reply-To: <54742FBD.802@hoa-project.net>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC] Unicode Escape Syntax
From: cmbecker69@gmx.de (Christoph Becker)

Ivan Enderlin @ Hoa wrote:

> Le 24/11/2014 23:09, Andrea Faulds a écrit :
>> Good evening,
>>
>> Here’s a new RFC: https://wiki.php.net/rfc/unicode_escape
>>
>> It has a rationale section explaining why certain decisions were made,
>> that I’d recommend you read in full.
> Excellent RFC, thank you for this proposal.
> I would suggest this talk
> https://speakerdeck.com/mathiasbynens/hacking-with-unicode (you might
> already know) but interesting concepts and limitations of current
> Unicode implementations are mentioned.
> The usage of `\u{…}` fixes most limitations and I could not be more
> agree with that notation!

I don't see that the proposed \u{...} notation fixes any limitation.
Its only advantage would be slightly better readability opposed to
inserting the desired UTF-8 byte sequences as octal or hexadecimal
escapes.  For instance, all of the following would print Ä (in an UTF-8
context):

  echo "\u{00C4}";
  echo "\xC3\x84";
  echo "\303\204";

-- 
Christoph M. Becker