String reboot - (1a) incidental whitespace

[Jim Laskey]

I had a prototype ready with opening delimiter influence, which worked quite well. What kills the concept is that ODI is not reproducible in a library method.

How ODI works in the compiler is that it counts the number of characters in the scan buffer, starting at the start of line, leading up to the literal content after the open delimiter.  Once scanned, the literal contains no information that could help us regenerate the count.  The only options I can see to support the idea in full are,

1) always trim lines to only include characters right of the open delimiter

// Assuming auto alignment turned off
String m = """line 1
	      line 2
	     line 3
           """;
                      
Result:
line 1
line 2
ine 3

or 2) add equivalent whitespace to the head of the string to compensate for the lead up to the first line of content.

// Assuming auto alignment turned off
String m = """line 1
	      line 2
	     line 3
           """;
                      
Result:
              line 1
	      line 2
	     line 3


Not sure either are forward thinking.

Cheers,

-- Jim


> On Apr 17, 2019, at 7:37 PM, Liam Miller-Cushon <cushon at google.com> wrote:
> 
> On Wed, Apr 17, 2019 at 7:22 AM Jim Laskey <james.laskey at oracle.com <mailto: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/20190418/59c09d18/attachment-0001.html>