On Sep 30, 2019, at 9:05 AM, Maurizio Cimadamore <[email protected]> wrote: > > ``` > Add text blocks to the Java language. A text block is a multi-line string > literal that avoids the need for most escape sequences, automatically formats > the string in a predictable way, and gives the developer control over format > when desired. This is a preview language feature > <https://openjdk.java.net/jeps/12> in JDK 13. > ``` > > Now, I get the subtle distinction between multi-line in the source and > multi-line in the result value - but it's subtle, and I think the JEP should > at least be made clearer in that respect. >
I like this suggestion. Looking closely at the phrase "multi-line string literal”, I think it is ambiguous to parse. So, “(multi-line string) literal” would be “a literal for a string with newlines in it”, which we have today. And “multi-line (string literal)” would be “a string literal whose syntax contains line breaks”. The latter is the new thing. The JEP should probably explain the difference between the former and the latter, one way or another, and either use less ambiguous language or disambiguate some other way (via an explanation). The benefit of an updated *string literal* that has *line breaks* is that the source form of the string can be arranged for better readability. It’s not like we can express new sequences of characters; it’s about prettier literals. And that, in turn, amply motivates the latest proposals (IMO), since supporting \s and \<LT> gives users some very useful control over the esthetics of their literals. The rules for stripping leading blanks are very good for controlling the horizontal position of a literal’s contents, but they don’t help (and sometimes hurt) working with very long lines. For that, you need a directive to paste two source lines together in one payload line, just as \n splits one source line into two payload lines. In the end, most source newlines will (and should) correspond to payload newlines, but there will always be cases where one source line should be broken (with \n) into two payload lines and vice versa (with \<LT>). These two cases are roughly symmetrical with each other. — John
