RFR: JDK-8198986 - 3.10.7: Raw string literals
brian.goetz at oracle.com
Wed Mar 14 18:23:49 UTC 2018
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.
More information about the amber-dev