I lke the r prefix because most people think the r prefix means regular expression.
Rémi > De: "Brian Goetz" <brian.go...@oracle.com> > À: "amber-spec-experts" <amber-spec-experts@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:scolebou...@joda.org | >> scolebou...@joda.org >> ] > >> Subject: Re: String reboot (plain text) >> Date: March 21, 2019 at 11:14:53 AM EDT >> To: [ mailto:amber-spec-comme...@openjdk.java.net | >> amber-spec-comme...@openjdk.java.net ] >> Cc: Brian Goetz < [ mailto:brian.go...@oracle.com | brian.go...@oracle.com ] >> > >> On Wed, 13 Mar 2019 at 17:52, Brian Goetz < [ mailto:brian.go...@oracle.com | >> brian.go...@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 >> ]
