Raw string literals and Unicode escapes

[John Rose]

On Feb 26, 2018, at 1:29 PM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
> 
> On 26/02/18 20:17, John Rose wrote:
>> Any *finite choice* of end-quotes has the same problem, with
>> a non-zero probability that decreases (but does not vanish)
>> with the number of available end-quotes.  The only way to
>> break out of the box is to allow the user an unlimited range
>> of successively "stronger" end-quotes (i.e., less likely ones).
> In reality there is a 'finite' upper bound for this length, which is given by 2^16 /2 = 2 ^ 15. That's the maximum delimiter size you could encode in a Java String which you can also symmetrically close - and it's an edge case, as it will contain the empty string.

That's only true for constant pool strings; there is no such defined limit
in the JLS.  And condy lifts the limit in the constant pool.

This is the point at which we need to note that there is a soft upper bound
to raw string literals, which is the amount of stuff you are willing to paste
into your Java source file before it isn't Java source any more.  Probably
a half-page of code will be the usual jumbo size, with occasional multi-page
outliers.  That's maybe 1kb (30 lines of 30 chars).  Still, that is plenty long
enough to encounter lots of odd corner-case end quotes.

> So, yes, on paper, I agree with the argument, in practice, I guess I'd me more in favor of limiting the number of repetitions

Pick your puzzler.  I'd rather not leave a single string un-representable; that
would lead to a different kind of puzzler, *as well as* a hard limitation.

Test question:  Does the JLS have a maximum length for identifiers?
It does not.  Even though long identifiers hypothetically lead to "puzzlers"
involving abuses of the notation.  Ridiculously long or difficult-to-read
identifiers are naturally avoided in practice, and the same will be true
for ridiculously long end-quotes.

http://merriam-webster.com/dictionary/abusus+non+tollit+usum

— John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20180226/b30ce903/attachment-0001.html>