String reboot (plain text)

[Brian Goetz]

In general, being able to break things down into orthogonal primitives leads to a more expressive and simpler outcome.  If we squashed the two features together, the outcome would be that we have two non-primitive, non-orthogonal string features — “old strings” (which are single-line and have escaping) and “new strings” (which are multi-line, have automatic reflow, some anomalies surrounding starting with quotes, and no escaping.)  You could argue that a menu of two very different items gives you more chances to have something that is close to what you want, but I think the burden is high to justify an ad-hoc alternate way to do something that you could already do.  (The previous RSL proposal, the one we almost went out with, was exactly such an ad-hoc way to do things that could already be done.)  

Would it have been a disaster? No, of course not.  But I think _any_ of the options on the menu I outlined in the previous mail are substantially better than the previous proposal.  They are all grounded in simple, mostly-orthogonal variations on the basic theme of string literals (tied together with a common syntactic approach — which the previous RSL proposal also lacked.)  

“Raw, except for line terminator normalization, and text flowing, and maybe later interpolation” is not an easy concept to explain or understand, because it couples multiple unrelated things.  

(To the “indent is good enough” point: Auto reflow is a disaster when applied to mixed spaces and tabs; while in general one should avoid this, I cannot rule out the possibility that someone might actually want to embed such a snippet; in that case, truly raw strings are an option.  If we take away truly raw, now they just have two bad approximations.)  



> On Mar 13, 2019, at 3:42 PM, Liam Miller-Cushon <cushon at google.com> wrote:
> 
> On Wed, Mar 13, 2019 at 12:10 PM Brian Goetz <brian.goetz at oracle.com <mailto:brian.goetz at oracle.com>> wrote:
> For example, we miss out on the opportunity to do text reflow on non-raw-ML strings and not do it on raw-ML strings (I don’t think we can really justify doing it automatically on raw strings; that’s not what raw means.)
> 
> For my understanding, is this something you could expand on?
> 
> I appreciate the pedagogical simplicity of "raw means raw", instead of having to understand nuances of automatically adjusting indentation when thinking about raw strings. There are clearly tradeoffs here, but it isn't obvious to me that reflowing indentation for raw strings is fatally flawed. And there are advantages: it decouples formatting and indentation choices from the value of the string literal, and many raw strings (especially foreign code) won't care about the leading whitespace anyway, and for cases where the leading whitespace is needed there are advantages to a library solution (reading `.indent(20)` is easier than counting 20 spaces).
> 
> One thing I found noteworthy from the swift proposal was that both their multi-line and raw strings automatically manage leading indentation.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20190313/b8e416c8/attachment.html>