Text blocks / Multi-line string literals

Stephen Colebourne scolebourne at joda.org
Mon May 13 19:18:42 UTC 2019


https://bugs.openjdk.java.net/browse/JDK-8222530

Some thoughts on where the proposal has reached.

1) I'm broadly happy.

2) I prefer "multi-line string literals" to "text blocks".

3) The proposal is a little bit hostile to Markdown, because markdown
relies on significant whitespace at the end of the line. I'd really
like to see a new escape \s for \u0020 added at the same time as this
feature to ensure there is a way out of the problem.

4) I'd also like to see \<NewLine> added at the same time as discussed
elsewhere.

5) I'm still unconvinced by the use of the closing delimiter to
determine indentation. To my eye, the examples all look a bit ugly
because they effectively require the closing delimiter in line with
the significant text. I don't think that plays well when passing the
text block directly to a method. My natural style would be to place
the closing delimiter 4 spaces to the left of the significant text.
More broadly, I think the closing delimiter rule is turning what
should be a code style choice (where the delimiter goes) into
something more significant. Having said this, the rules as defined are
a solid enough choice with logical rationale, even if not my choice.

6) The issue around concatenating strings with text blocks will trip
people up I think. Is it possible to add an additional rule? If a text
block opening delimiter follows a string concatenation operator (+)
then any text immediately following the opening delimiter is not an
error and that line is not stripped. And when concatenating, a single
line text block is allowed (not stripped). With these extra rules,
concatenation would work as expected I think.

String source = """
  public void print(""" + type + """ object, """ + otherParams + """) {
    System.out.println(Objects.toString(object));
  }
""";

Note, I don't think this is a deal-breaker, but I do think developers
would naturally expect concatenation to work in the case outlined
above.

thanks
Stephen


More information about the amber-dev mailing list