String reboot (plain text)

[Remi Forax]

I lke the r prefix because most people think the r prefix means regular expression. 

Rémi 

> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Envoyé: Samedi 6 Avril 2019 17:47:25
> Objet: Fwd: String reboot (plain text)

> Received on amber-spec-comments. These are mostly comments on syntax options
> that are for later parts of the discussion, so I’m reading them into the record
> now, and we’re going to leave them to sit until then.

> High-order summary:
> - Please consider prefixes a”…” for auto-align and r”…” for raw.

>> Begin forwarded message:

>> From: Stephen Colebourne < [ mailto:scolebourne at joda.org | scolebourne at joda.org
>> ] >
>> Subject: Re: String reboot (plain text)
>> Date: March 21, 2019 at 11:14:53 AM EDT
>> To: [ mailto:amber-spec-comments at openjdk.java.net |
>> amber-spec-comments at openjdk.java.net ]
>> Cc: Brian Goetz < [ mailto:brian.goetz at oracle.com | brian.goetz at oracle.com ] >

>> On Wed, 13 Mar 2019 at 17:52, Brian Goetz < [ mailto:brian.goetz at oracle.com |
>> brian.goetz at oracle.com ] > wrote:

>>> So, in the spirit of “keep ordering until sated, but stop there”, here are some
>>> reasonable choices.

>>> 1. Do multi-line (escaped) strings with a “”” fixed delimiter. Large benefit,
>>> small cost. Most embedded snippets don’t need any escaping. Low cost, big
>>> payoff.

>>> 1a. Do 1, but automatically reflow multi-line strings using the equivalent of
>>> String::align. There have been reasonable proposals on how to do this; where
>>> they fell apart is the interaction with raw-ness, but if we separate ML and
>>> raw, these become reasonable again. Higher cost, but higher payoff; having
>>> separated the interaction with raw strings, this is more defensible.

>>> 2. Do (1) or (1a), and add: single-line raw string literals delimited by \”…”\.

>>> 2a. Do (1) or (1a), and also support multi-line raw string literals (where we
>>> _don’t_ automatically apply String::align; this can be done manually). Note
>>> that this creates anomalies for multi-line raw string literals starting with
>>> quotes (this can be handled with concatenation, and having separated ML and
>>> raw, this is less of a problem than before).

>>> 3. Do (2) and (2a), and also support a repeating compound delimiter with
>>> multiple backslashes and a quote.

>> My views have not changed dramatically from my last mail [1]. As per
>> these options, I think the language would benefit from 1, 1a, 2 and 2a
>> type changes. I think the choice between 1 and 1a is a false one. I'm
>> not convinced 3 is worth pursuing.

>> I agree that triple double-quote is the right mechanism for multi-line
>> strings - an obvious direction for Java. I'm happy to accept 1 on its
>> own *providing that 1a can be added later*. My preference is for """
>> to be the delimiter for non-aligned multi-line strings, and for a
>> single letter prefix 'a' to be used for aligned strings, eg. a""" ...
>> """

>> For raw strings I personally find the syntax /" ... "/ or /""" ...
>> """/ unpleasant. While the argument of "distributing the escape over
>> the string" makes some sense in the abstract, the result is not
>> appealing to read. Given that I believe aligned and non-aligned
>> strings should be separated by a single letter prefix, I believe that
>> raw strings and non-raw strings should also be separated by a single
>> letter prefix:

>> """ - multi-line with-escapes & non-aligned
>> a""" - multi-line with-escapes & aligned
>> r""" - multi-line raw & non-aligned
>> ra""" - multi-line raw & aligned
>> " - single-line with-escapes
>> r" - single-line raw

>> And yes, I do think you can have raw and aligned as a combination. I
>> think using prefix letters is more extensible, more orthogonal and
>> clearer than using /""" ... """/.

>> thanks
>> Stephen

>> [1] [ https://mail.openjdk.java.net/pipermail/amber-dev/2019-January/003850.html
>> | https://mail.openjdk.java.net/pipermail/amber-dev/2019-January/003850.html ]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20190406/bb67982a/attachment-0001.html>