Raw String Literals (RSL) - indent stripping of multi-line strings

Kevin Bourrillion kevinb at google.com
Fri Apr 27 01:25:10 UTC 2018


Jim,

I may be missing something. I was feeling content about a "best effort"
model of only removing the maximal *identical* prefix from each line. It
seems it would work perfectly in the two hygienic cases (cf. my previous
message), and that in the non-hygienic case, there's no good solution no
matter what we do. They have to either clean up their act or use
stripMarkers. Or, if we want to still give them a stripIndent() method, and
detab(int), they can put the closing tick all the way left and then call
.detab(8).stripIndent(). Okay, that's gross, but again... no good solution.

I know the non-hygienic case is real and may even be the majority of Java
code. But if they allow that into their string literals, they're going to
have a bad time regardless. Note

I hope we don't have to sacrifice the best behavior for the hygienic cases
to accommodate this one.

(I guess that one other way to implement "best effort" for these cases is
to specify that, sorry, we defined the tab stop to be 8 (or 4, or
whatever). That's unpleasant because it means there are some projects
you'll just constantly be wrong for. It would provide good behavior for
whomever we happened to guess right for, but is probably not worth it. Note
that I have no idea what the histogram of tab stop preferences for projects
in the wild looks like. Is one dominant? I don't know. Don't some projects
that prefer indentation with tabs do that because they want to let
different developers set their tab stop differently?)



On Thu, Apr 26, 2018 at 6:04 PM, Jim Laskey <james.laskey at oracle.com> wrote:

(we can not in the tab war business),
>

I'm guessing that's "win".

I'm not sure about this.  As long as we never had raw string literals, it
was easy to stay above that fray; there's no real reason to care one way or
the other. But tabs inside your RSLs are quite different. Now it's program
data.

And it's not as if both sides are equal. A space is a character that has a
well-defined meaning. A tab is anyone's guess what it's going to do. It
does something different based on what came before it, and based on local
environment. If the best we can do here ends up treating spaces as
privileged over tabs... so be it?

(But again, I'm not *suggesting* to favor spaces over tabs, but rather, to
favor the two hygienic cases over the unhygienic one, and only because
there is no real attainable victory for the latter.)

-- 
Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com


More information about the amber-dev mailing list