Wrapping up the first two courses

[Kevin Bourrillion]

On Fri, Apr 26, 2019 at 8:39 AM Brian Goetz <brian.goetz at oracle.com> wrote:

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.)
>

Apparently bash's behavior is to replace <any amount of whitespace,
backslash, newline, any amount of whitespace> with a single space
character, and that at least seems like a *useful* behavior for us too if
we're open to it.


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

Hmm, I can see how that could be harmless but it seems to blur the boundary
between the features to me.
But I've lost track of why we need triple-quote to be different from
single-quote in the first place. *Could *the notion just be that if you
newline immediately after opening quote then you are asking for MLS with
everything that comes along with that?

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?
>

So sorry: I meant vs. 6 months ago, not that this is new.

I know I complained about our going back to the drawing board then, but
where this thread is going now is making us much happier than before.



-- 
Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20190426/883475a2/attachment.html>