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

[Dan Smith]

> On May 15, 2019, at 11:35 AM, John Rose <john.r.rose at oracle.com> wrote:
> 
> 2/4. Dan, I'm having trouble seeing your
> idea of "prefix" in this example.  Is it that
> `String code = ` has the same number of
> chars as there are spaces before `public`
> (start of the first payload line)? This is hard
> to read, I'm afraid.

Yes. "Same number of characters" is the idea (with extra constraints to handle tabs and other exotic whitespace, but most people won't care about those).

Is it hard to read because of a variable-width font? In a normal editing environment, I'm just saying the opening delimiter should be visually aligned with the content.

> 3/4. Dan, isn't it true that programmers can
> use this idiom under the existing proposal,
> without appealing to your "prefix" rule?
> All they do is (a) keep the close-quotes
> (in a single ""+x+"" expression) aligned,
> and also (b) don't exdent before the close
> quotes.

Sure. I'm claiming that it would be helpful to put some additional constraints on what constitutes a valid text block, in order to ensure some harder-to-read cases never come up.

> 4/4. I guess you are proposing two adjustments, the
> "prefix" rule and the "no exdent rule".  The "prefix"
> rule allows open-quote to set indentation, by counting
> arbitrary characters before the open-quote as setting
> a target column.  The "no exdent rule" disallows payload
> chars in columns before the target column, as set by
> the close-quote.

You could say that. Your "no exdent" rule prevents any lines but the (necessarily blank) closing-delimiter line from setting the target column. Your "prefix" rule transfers this responsibility to the opening-delimiter line. I think using the opening delimiter is helpful because 1) readers see the opening delimiter first, and 2) it frees the closing delimiter to be a marker for trailing whitespace/newlines.