String reboot - (1a) incidental whitespace

[Liam Miller-Cushon]

On Wed, Apr 17, 2019 at 7:22 AM Jim Laskey <james.laskey at oracle.com> wrote:

> We need a strong argument for why to not allow content on the same lines.
>
...

> Let's go back to having close delimiter influencing indentation and the
> original close delimiter influencing presence of trailing \n.  Can we have
> both?  Do they conflict?  If so, how do we counteract the default action?
>
...

> So we can have both close delimiter influences, with workarounds for the contrary
> cases.
>

I found the examples you worked through of why the restriction is
unnecessary for closing delimiters convincing. Thanks for the explanation!

The 'failure mode' of needing a call to `.indent(4)` doesn't really feel
like losing: arguably it helps readability, since reading '4' is easier
than visually counting whitespace characters.

I still find the restriction appealing for the opening delimiter, though.
The argument is that having contents on the opening line seems likely to
cause confusion, e.g.:

        String m = """    +--------+
                          |  text  |
                          +--------+""";

Result of variable m under the current string-tapas prototype:

....+--------+\n
|..text..|\n
+--------+

Unlike the issue with trailing newlines and the closing delimiter,
disallowing contents on the same line as the opening delimiter doesn't
limit the set of strings that can be expressed using triple quotes.

Are there important use-cases that require allowing contents on the same
line as the opening delimiter?

(The other way to "fix" this example would be using information from the
scanner, but there seems to be tentative consensus that cure is worse then
the disease.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20190417/a545a4e6/attachment.html>