RFR: Multi-line String Literal (Preview) JEP [EG Draft]
amaembo at gmail.com
Thu May 9 15:59:11 UTC 2019
Great draft, thank you. I'm especially happy that the expert group came to
the conclusion that automatic builtin processing of the indentation is
important. I proposed to do this in January, 2018 . While the solution
proposed in JEP draft is not as radical as proposed by me, I still like it
better than the previous RSL proposal.
One thing which seems missing is dealing with tabs. What if user file is
invented with tabs? Should they be also processed? More specifically, what
is a "white space" in strip indent algorithm description? Only \u0020
symbol or \u0020 & \u0009? Or anything for which Character.isWhiteSpace()
returns true? Also if tabs are included do single tab costs the same as
single space? You may imagine that somebody pastes part of multiline string
from StackOverflow where tabs were used for indent and see some unexpected
results (e.g. indent changes for the untouched lines while visually in the
editor pasted lines look having the same indent as surrounding ones). I
admit that defining what is "expected result" is hard, especially taking
into account that most editors provide a setting for the tab size and
different users may have different tab size. Nevertheless I feel that tab
handling should be explicitly spelled out (even if it's "tab is not
considered as a white-space character").
With best regards,
чт, 9 мая 2019 г., 19:07 Jim Laskey <james.laskey at oracle.com>:
> At this point I think the only outstanding issue is long line
> continuation. While we can postpone continuation until a later release, I
> think we should at least lay out the details to see if we need to do
> anything now. I'll follow up with a (long line continuation) synopsis
> e-mail in a few.
> Meanwhile, please review the JEP and comment back here.
> -- Jim
More information about the amber-spec-observers