Wrapping up the first two courses

Brian Goetz brian.goetz at oracle.com
Fri Apr 26 15:38:56 UTC 2019


>
>
>     Other notion mentioned;
>
>     - \<Line Terminator> eats the terminator and continues on the next
>     line.
>
>
> Eats the terminator plus all leading whitespace of the next line, 
> yes?  I had forgotten that the reintroduction of escapes opened up 
> this possibility, and I think it's pretty great -- quite a substantial 
> fraction (25%+ I think) of all our multiline use cases that we've 
> found are things like long exception messages where they don't 
> actually want the newlines, they just want to be free of dealing with 
> the damn quote-plus-quote.

There are two interpretations here, related to escape-then-align vs 
align-then-escape.  Since everything else is align-then-escape, what 
this would mean is we'd consider the leading space on the continuation 
line for purposes of determining a common prefix, and strip the common 
prefix from that, THEN eat the newline.  Example:

     String s = """
         Imagine this line\<terminator>
         was very long""";

which would result in:

Imagine this linewas very long

(lack of space between "line" and "was" is not a typo.)

Which raises another question: do we allow \<terminator> in SL strings?  
(I presume so, and we just eat the \ and the terminator.)

> Oh, and quite a few of /those/ use cases are in annotations like 
> @FlagSpec({"--foo", "long help text about --foo"}), and I'm very happy 
> that these are no longer excluded from indentation stripping.

Can you expand this point?  Not sure what you mean by "no longer 
excluded from indentation stripping", or why it makes you happy. Can you 
just give a before/after example for what you mean?


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


More information about the amber-spec-experts mailing list