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