Text blocks / Multi-line string literals

[Alex Buckley]

On 5/13/2019 12:18 PM, Stephen Colebourne wrote:
> 2) I prefer "multi-line string literals" to "text blocks".

I know where you're coming from, but let me explain. The feature 
proposed by the JEP _is_ a multi-line string literal, but also much 
more. There is enough depth to the feature that focusing on 'multi-line' 
would miss an opportunity to best set developer expectations on Day One. 
Consider:

- Content doesn't start immediately after the opening """ -- this is NOT 
what someone with 'string literal' on their mind would expect.

- Content is rectangularized/deincidentalized by the re-indentation 
algorithm -- wholly unlike anything in string literals.

- Line terminators are normalized -- again novel.

In addition, focusing on any kind of 'string literal' would set an 
expectation (perhaps a light one, but still there) of the delimiter 
being `"` when plainly it is not. Also, overloading a term ('string 
literals' and 'multi-line string literals') is best avoided because it's 
too easy in informal contexts to use the shorter phrase when you mean 
the longer phrase.

I think the rest of your mail showed that "text block" is an easy name 
to speak of. The block-ness alludes to how, much of the time, the reader 
will be entering a new context within the delimiters -- a context of 
balanced <..> </..> elements, or CAPITALIZED SQL STATEMENTS. Whereas { 
starts a new context for Java code, """ starts a new context for 
(usually) non-Java code.

Alex

> 5) I'm still unconvinced by the use of the closing delimiter to
> determine indentation. To my eye, the examples all look a bit ugly
> because they effectively require the closing delimiter in line with
> the significant text. I don't think that plays well when passing the
> text block directly to a method. My natural style would be to place
> the closing delimiter 4 spaces to the left of the significant text.
> More broadly, I think the closing delimiter rule is turning what
> should be a code style choice (where the delimiter goes) into
> something more significant. Having said this, the rules as defined are
> a solid enough choice with logical rationale, even if not my choice.
>
> 6) The issue around concatenating strings with text blocks will trip
> people up I think. Is it possible to add an additional rule? If a text
> block opening delimiter follows a string concatenation operator (+)
> then any text immediately following the opening delimiter is not an
> error and that line is not stripped. And when concatenating, a single
> line text block is allowed (not stripped). With these extra rules,
> concatenation would work as expected I think.