RFR: Multi-line String Literal (Preview) JEP [EG Draft]

[Guy Steele]

We have already discussed other conditions that can cause string literals to be rejected before the indentation stripper gets a crack at them. I see nothing wrong with stripIndent being a total function but also having the compiler filter string literals that appear in source code before the function. Is applied. (The filter predicate could also be in the library if we want.)

Sent from my iPhone

> On May 9, 2019, at 6:21 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
> 
> 
>> One possibility is language enforcement: at the part of the processing of a multiline string where whitespace is stripped off to the left of the rectangle, it could be an error if that leading whitespace is not “spelled the same” on all lines from which it is being stripped.  I lean toward recommending this.
> 
> I see the logic here, but it also makes me a bit uncomfortable.  Our story is that indentation-stripping is done by a JDK method (String::stripIndent), and that the language behavior is specified in terms of the library behavior.  (This is essential if we want to allow users to opt out, do some manipulation on the un-aligned form, and then perform alignment — the language and library behavior must be, er, aligned.). 
> 
> We could surely make String::stripIndent throw when you present it a mixed-whitespace string, but do we really want this?  I would prefer that stripIndent be a total function on strings, even if it has to produce ugly output when given ugly input.  
> 
>