Text blocks / Multi-line string literals

[John Rose]

On May 13, 2019, at 3:17 PM, Kevin Bourrillion <kevinb at google.com> wrote:
> 
> *From: *Stephen Colebourne <scolebourne at joda.org>
> *Date: *Mon, May 13, 2019 at 12:19 PM
> *To: *Amber dev
> 
> 2) I prefer "multi-line string literals" to "text blocks".
>> 
> 
> Like others, I am also liking "text blocks" for the connotations it gets
> across.

+1  Ever since I realized I wanted thin-strings to have a way
to break long lines, I knew that "multi-line string" was a misfit
for fat-strings.

> 
>> 3) The proposal is a little bit hostile to Markdown, because markdown
>> relies on significant whitespace at the end of the line. I'd really
>> like to see a new escape \s for \u0020 added at the same time as this
>> feature to ensure there is a way out of the problem.
>> 
> 
> That seems like a great idea to me…

Just to rub everyone's nose in it again, \0020 is currently
indistinguishable from a plain space.  So \s (which I support)
would be a new escape for \040 and **NOT** for \u0020.

…Unless we take up my proposal to adjust the phasing of
7-bit ASCII unicode escapes inside of strings.  I'm serious
about that, and we could use a bit of the framework
for those developed for raw strings to make it happen.
The essential idea is that javac translates those guys
early as required by today's JLS, but remembers where
they were, and it watches for those to occur inside
string literals (no other context).  If it finds that some
7-bit ASCII character arose from some \u00XX in
the earlier phase, javac would **UNDO** the escape
transformation and present the escape characters to
the library routine that handles all escapes.  There
would have to be an edge case for processing \u escapes
on the edge of the string, that is, the open and close
quotes.  Those would either be illegal, or would suppress
the special "undo" feature I am proposing.

This special "undo" feature is useful to resolve programmer
confusion about \u0020.  Given that the programmers on
*this* list are confused about it, most of the rest of the 10M
Java programmers will be confused also.  Let's remove that
stumbling block with some kind of undo rule for \u in strings!

> 
>> 4) I'd also like to see \<NewLine> added at the same time as discussed
>> elsewhere.
>> 
> 
> I'm okay if it (and the previous) have to wait in order to make the
> schedule, but yeah, they are very helpful to making the feature fully
> adoptable and usable.

+1 on all counts

> 5) I'm still unconvinced by the use of the closing delimiter to
>> determine indentation.
> 
> 
> I hear you on the style preference. If my text blocks are going to be
> parsed by a whitespace-ignoring parser, I might still indent them from the
> fat quotes because I can.
> 
> But I think the text being directly above the quotes looks considerably
> uglier than it *will* after we're accustomed to it. It's livable, and it's
> a such a very useful design choice…

Yep.