RFR: JDK-8198986 - 3.10.7: Raw string literals

[Brian Goetz]

For the record, we explored these approaches, and, while we also liked 
them for the first few minutes (probably for the same reason you do), 
they eventually lose their lustre.

Stepping out of the micro-syntactic morass, the primary goal of this 
feature is to make it possible to take a well-formed snippet of some 
other language (SQL, Regex, JSON, HTML, Python, whatever) and embed it, 
_free of the need to do any localized fixups_, in Java code.  Picking a 
fixed number of ticks, plus an escaping rule, may make it less likely 
you have to do fixups, but ultimately just moves the problem down the 
road.  The N-delimiter solution allows you to pick a non-conflicting 
delimiter, and then not have to fuss with the snippet _at all, ever_.

For common cases (where a program has no or single or double embedded 
ticks), the result is equivalent to having picked three ticks, but more 
flexible.  I get that you would rather not have that flexibility, but 
you must also get that there's room for reasonable people to disagree on 
where to draw the line?



On 3/14/2018 2:02 PM, Stephen Colebourne wrote:
> On 13 March 2018 at 23:36, Stephen Colebourne <scolebourne at joda.org> wrote:
>> On 13 March 2018 at 23:10, John Rose <john.r.rose at oracle.com> wrote:
>>> While you say you would prefer to hunt through
>>> the body of the string looking for doubled backticks,
>> No, I expect my IDE to double the backticks when I paste. In the
>> unlikely event that there are backticks.
> For the record, I'd also find a syntax with a fixed number of
> backticks/quotes and no escaping preferable to the unlimited backticks
> of the Oracle proposal.
>
> `````` = "" (empty)
> ``````` = "`" (single backtick)
> ````AAA```` = "`AAA`" (AAA surrounded by backticks)
>
> While there is the very rare scenario it can't cope with, it is far
> less puzzler strewn.
>
> Stephen