multiline: Must we waste one of the final few 'free' symbols on this?

[Brian Goetz]

It would surely be possible; the JEP refers to several existence proofs, 
and approaches like this were considered.

I appreciate that you are concerned with the stewardship concern of 
managing our limited syntactic real estate.  We of course pay 
considerable attention to this concern as well.  Like any finite 
resource, you want to spend it carefully, but you also don't want to 
hoard it and never spend it.  Always a tough choice.

As to who would speak against it: I think probably almost everyone, at 
least in one aspect: it's pretty heavy, often unnecessarily so.  For 
strings not containing single backticks (which already describes the 
vast majority of string literals), you don't need double or triple anything:

     String s = `I'm a raw string`;

Many users feel that the triple (or more) quotes are about as subtle as 
a hammer to the head.  Here, you only need to trot out the triple-quotes 
here if your embedded text has both single and double quotes in it already.

Is it perfect?  Of course not.  Is the """ approach obviously better?  
Also not.  Such is the nature of syntax selection; there's a lot of room 
for personal choice.





On 3/1/2018 1:16 PM, Cyrill Brunner wrote:
> The points raised in that discussion are valid reasons for not using 
> fixed, possibly single-letter delimiters for raw strings, yes.
> But for the second suggestion made, would it not also be a possible to 
> use 3+, symmetric double quotes? It would leave the use case of 
> `while` etc. open whilst producing none of the detriments mentioned in 
> the JEP directly.
>
> So instead of
>
> String text = ``This contains a backtick: `.``
>
> you could similarly do
>
> String text = """"This string contains a triple quote: """.""""
>
> This would leave ` untouched for now, just as string"prefixes", whilst 
> still allowing the arbitrary-but-symmetric number of double quotes.
>
> What would speak against this?
>
> - Cyrill Brunner
>
>
> Am 28.02.2018 um 14:24 schrieb Remi Forax:
>> see 
>> http://mail.openjdk.java.net/pipermail/amber-spec-experts/2018-February/000286.html
>>
>> Rémi
>>
>> ----- Mail original -----
>>> De: "Reinier Zwitserloot" <reinier at zwitserloot.com>
>>> À: "amber-dev" <amber-dev at openjdk.java.net>
>>> Envoyé: Mercredi 28 Février 2018 07:06:20
>>> Objet: multiline: Must we waste one of the final few 'free' symbols 
>>> on this?
>>> Some feedback on multiline string literals. Where 'proposal' is 
>>> referenced,
>>> it refers to: https://bugs.openjdk.java.net/browse/JDK-8196004
>>>
>>> # Must we waste one of the final few 'free' symbols on this? #
>>>
>>> If you look at all easily accessible symbols on a keyboard, the only 
>>> ones
>>> that don't yet have a syntactic meaning in java source files are the
>>> backtick and the hash. Everything else is either defined to be an
>>> identifierpart which makes using them as a symbol somewhat difficult
>>> (that'd be the underscore and the dollar, although the underscore has
>>> already backwards-incompatibly been torn out; presumably the dollar 
>>> can be
>>> 'rescued' in the same fashion). Is THIS what we're going to spend 
>>> one of
>>> our final 2 to 3 symbols on?
>>>
>>> One obvious alternate use for the backtick is for encoding 
>>> identifiers; if
>>> you want to name a method "while", which the JVM spec does allow you 
>>> to do,
>>> you could maybe one day use backticks. Some JVM-targeted languages 
>>> already
>>> do this. I'm not saying this is a good idea, but I am saying that
>>> implementing the raw string literal proposal as written pretty much
>>> eliminates this notion from ever seeing the light of day, forever. 
>>> Perhaps
>>> it's worth some debate before we just casually close that door in
>>> perpetuity.
>>>
>>> alternatives:
>>>
>>> Is: R"This is a raw string" an option? An advantage to the 'R' 
>>> concept is
>>> that you can separate 'escapes arent processed' ('raw') from 'feel 
>>> free to
>>> newline in these' ('multiline'): The R indicates raw, and hitting enter
>>> immediately after the quote indicates multiline, which would be 
>>> backwards
>>> compatible as currently its always illegal java if you newline in the
>>> middle of string literals. Thus:
>>>
>>> String x = R"Escapes \t are not processed here; this contains raw
>>> backslash-t instead of a tab";
>>> String multi = "
>>>     This is
>>>     multiline but \t DOES contain a tab";
>>> String rawMulti = R"
>>>     This is
>>>     multi with \t backslash-t literally, not a tab";
>>>
>>> Another option would be to investigate the use of triple quotes. In 
>>> java9
>>> syntax, having 3 quotes in immediate succession cannot possibly be 
>>> valid in
>>> a source file unless in a comment. Therefore, it would seem possible 
>>> to use
>>> triple quotes as a delimiter without creating the ambiguity 
>>> mentioned in
>>> the 'Choice of delimiters' section. Example:
>>>
>>> String regex = """Hey now I don't have to \w+ escape my 
>>> backslashes!""";
>>>
>>> This syntax also has quite a lot of precedence (kotlin, swift, 
>>> groovy, and
>>> python). Note that the 'other languages' section misconstrues how 
>>> python
>>> works; triple quotes is for multiline strings. For raw strings, you use
>>> R"foo". Most python programmers seem to think the R stands for 
>>> regex, as
>>> that's pretty much what they're always used for. Nevertheless, it 
>>> stands
>>> for 'raw'. See:
>>> https://docs.python.org/3/reference/lexical_analysis.html#string-and-bytes-literals 
>>>
>>>
>>> In regards to investigating simply allowing java strings to contain
>>> newlines; the 'Choice of delimiters' section has this quote:
>>>
>>>> Enabling such a feature would affect tools and tests that assume
>>> multi-line traditional string literals as an error.
>>>
>>> This makes no sense. Any unupdated tool would consider use of a 
>>> backtick
>>> also an error. Either way, tools not aware of the new feature would 
>>> treat
>>> multiline string literals as a syntax error, whether you use backtick,
>>> quote, or triple-quote. Unlike the introduction of very fancy 
>>> footwork to
>>> treat backslash-u escapes as raw inside these literals, addition of
>>> backtick (or triple quote, or single quote) as signifying raw and/or
>>> multiline strings won't be particularly difficult for existing java 
>>> parsers
>>> to implement. It doesn't seem relevant as an argument for or against 
>>> any
>>> particular delimiter.
>>>
>>>   --Reinier Zwitserloot
>