[raw-string] indentation stripping

[Guy Steele]

> On May 1, 2018, at 4:46 PM, Kevin Bourrillion <kevinb at google.com> wrote:
> 
> (None of this has any bearing on single-line RSLs, which work great and need no changes at all. "Raw means raw", all the way.)
> 
> I've proposed we adopt an assumption, which I was calling the "rectangle rule", which really just says: we assume most users will prefer to see relative indentation preserved exactly between the source code and runtime forms of their strings.
> 
> That is, I think we can assume that users will not want to read or write this:
> 
>   String one = `+-----------------+
> | a nice neat box |
> +-----------------+`;
> 
> nor this:
> 
>   String two = `+-----------------+
>       | a nice neat box |
>       +-----------------+`;
> 
> nor even this:
> 
>   String three =
> `+-----------------+
> | a nice neat box |
> +-----------------+`;
> 
> but that the universe of styles they will consider might include this:
> 
>   String four = `+-----------------+
>                  | a nice neat box |
>                  +-----------------+`;
> 
> or this:
> 
>   String five = `
>       +-----------------+
>       | a nice neat box |
>       +-----------------+
>   `;
> 
> or this:
> 
>   String six = `
> +-----------------+
> | a nice neat box |
> +-----------------+`;
> 
> ... or various others, but common to all, I claim that users will want to see... well, a nice neat box.
> 
> If we agree with this principle, then continuing with "raw means raw" creates a big problem: everything but style four gives you a leading newline in your actual constant, which is rarely wanted, and not even trivial to remove. And style four is itself problematic, because you may overflow your right margin, and because refactorings will break the alignment you wanted once again.
> 
> So I'm hoping to get agreement on this question: even if we do nothing else, should we chop a leading newline (after ignoring other leading whitespace), if present? For the reasons just explained I think the answer should be yes.
> 
> (My main project here is to get to a fair comparison between the "raw-means-close-to-raw" and the "automatic indentation stripping" alternatives. All I'm hoping to do here is to stop this leading newline issue from muddying that comparison, by establishing that we would strip that either way. Note that symmetric arguments do not apply for trailing newlines; in fact, for the more-raw alternative we must not strip those.)

If we do provide a way to strip that leading newline (whether “always" or through use of a library method), this suggests a seventh possible style:

  String seven = `
      +-----------------+
      | a nice neat box |
      +-----------------+
      `;

  String sevenLibrary = `
      +-----------------+
      | a nice neat box |
      +-----------------+
      `.trimIndentation();     // If a library method is used

with the convention that if the last line consists entirely of whitespace and does not end in a newline, then it should be stripped  _and furthermore the exact same amount of whitespace should be stripped from all other lines in the literal_.  Maybe this feature gets triggered in the automatic case only if a leading newline is also there to be stripped.

This strategy eliminates the need to use some special character such as | to delineate the indentation level.  And it nests properly:

  String myNestedExample = ```
    String seven = `
        +-----------------+
        | a nice neat box |
        +-----------------+
        `;
  ```;

In this last example, the nice neat box, once stripping has occurred, has no leading indentation, whereas the text that begins “String seven” has two spaces of leading indentation.

—Guy

P.S. We can actually have it both ways: do the stripping if and only if the number of tick marks is even.  :-b

  String myNestedExample = ````
    String seven = ``
        +-----------------+
        | a nice neat box |
        +-----------------+
        ``;
  ````;

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20180501/3b9fc89f/attachment-0001.html>