I was interpreting \<Line Terminator> as "the line is to be continued" and
\<Space> as "this is where the line continues". This interpretion provides the
margin control that Guy was looking for.
String s = """
\ This is the first bit
\ and the second bit
\ and the third bit
""";
Result:
This is the first bit
and the second bit
and the third bit
The string continues after the \<Space>, overriding the indentation control of
that line.
Revisiting the other cases;
String s = """
This is the first bit
and the second bit
and the third bit
""";
Result:
This is the first bit
and the second bit
and the third bit
Default case.
String s = """
This is the first bit \
and the second bit \
and the third bit
""";
Result:
This is the first bit and the second bit and the third bit.
Not because the next line's white space was skipped after the \<Line
Terminator>, but because of default align.
String s = """
This is the first bit \
\ and the second bit \
\ and the third bit
""";
Result:
This is the first bit and the second bit and the third bit.
Combining the two escapes.
> On Apr 26, 2019, at 12:31 PM, Kevin Bourrillion <[email protected]> wrote:
>
> On Thu, Apr 25, 2019 at 5:42 PM Brian Goetz <[email protected]
> <mailto:[email protected]>> wrote:
>
> So what you’re saying is: with CDI, the opt out is: bring the closing
> delimiter to the left margin, done.
>
> derp, thanks for completing my thought. Basically: some say "opt out" while I
> say "I choose to locate the left edge of my rectangle at the left edge of the
> actual source file". "Done" indeed.
>
>
> On Fri, Apr 26, 2019 at 6:25 AM Jim Laskey <[email protected]
> <mailto:[email protected]>> wrote:
>
> The example that Kevin left to the imagination was;
>
> String s = """
> some
> lines go here
> """;
>
> Which, while awkward, remains a natural progression of CDI, can be
> interpreted as heredoc, and no other indicator required.
>
> I persistently forget that people will sometimes want to do that, to keep
> their content within their customary source file column limit. (I want to
> downplay the notion of pasteability because that's precisely a feature of raw
> strings, which this is not.)
>
>
> Other notion mentioned;
>
> - \<Line Terminator> eats the terminator and continues on the next line.
>
> Eats the terminator plus all leading whitespace of the next line, yes? I had
> forgotten that the reintroduction of escapes opened up this possibility, and
> I think it's pretty great -- quite a substantial fraction (25%+ I think) of
> all our multiline use cases that we've found are things like long exception
> messages where they don't actually want the newlines, they just want to be
> free of dealing with the damn quote-plus-quote.
>
> Oh, and quite a few of those use cases are in annotations like
> @FlagSpec({"--foo", "long help text about --foo"}), and I'm very happy that
> these are no longer excluded from indentation stripping.
>
>
> - I suppose we could have \<Space> to mean continue here
> - This could effective provide margin control
>
> I have to catch up on this thread to figure out what this means.
>
> I also need to catch up on the issue of what to do with the trailing newline.
> We can get data on how often our string literals seem to want interior
> newlines but no trailing one. It would be a bit surprising if the trailing
> newline is automatically chomped, but at least you have two very simple and
> obvious ways to restore it (add another line or add `\n`), whereas chomping
> via library is sad for several reasons (including excluding those @FlagSpecs
> I mentioned above).
>
>
>>> On Apr 25, 2019, at 8:19 PM, Kevin Bourrillion <[email protected]
>>> <mailto:[email protected]>> wrote:
>>>
>>> I'm sure I'm not saying anything totally new in the following, but this is
>>> my summary of why I don't see the necessity of any explicit opt-out like \-.
>>>
>>> Suppose I write this:
>>>
>>> String s = """
>>> some
>>> lines go here
>>> """;
>>>
>>> And suppose I have learned to picture a rectangle whose left edge is the
>>> left edge of the ending delimiter.
>>>
>>> Well, once I'm already picturing that rectangle based on the delimiter,
>>> then clearly if I leave the delimiter alone, that leaves the rectangle
>>> alone. I can change to
>>>
>>> String s = """
>>> some
>>> lines go here
>>> """;
>>>
>>> ... to insert two spaces before `some`, and I can further change to
>>>
>>> String s = """
>>> some
>>> lines go here
>>> """;
>>>
>>> ... to also insert two spaces before `lines`.
>>>
>>> What is notable to me is that at no point did I ever change from one kind
>>> of string literal to another. There is no feature that I opted in or out of
>>> -- because there just doesn't need to be. That to me is a clear and
>>> compelling win for simplicity.
>>>
>>> It's entirely possible this was all 100% clear already, in which case sorry!
>>>
>>>
>>>
>>>
>>> On Thu, Apr 25, 2019 at 4:30 PM Liam Miller-Cushon <[email protected]
>>> <mailto:[email protected]>> wrote:
>>> On Thu, Apr 25, 2019 at 8:56 AM Brian Goetz <[email protected]
>>> <mailto:[email protected]>> wrote:
>>>
>>> > For 2/3, here’s a radical suggestion. Our theory is, a “fat” string is
>>> > one that is is co-mingled with the indentation of the surrounding code,
>>> > and
>>> > one which we usually wish the compiler to disentangle for us. By this
>>> > interpretation, fat single-line strings make no sense, so let’s ban them,
>>> > and similarly, text on the first line similarly makes little sense, so
>>> > let’s ban that too. In other words, fat strings (with the possible
>>> > exception of the trailing delimiter) must exist within a “Kevin
>>> > Rectangle.”
>>> >
>>>
>>> +1
>>>
>>> I thought Jim presented a good case for an exception for the trailing
>>> delimiter, but otherwise disallowing single-line 'fat' strings (single-line
>>> multi-line strings?) seems to mostly have upside.
>>>
>>> For 4 (opt out), I think it is OK to allow a self-stripping escape on the
>>> > first line (e.g., \-), which expands to nothing, but suppresses stripping.
>>> > This effectively becomes a “here doc”.
>>> >
>>>
>>> This seems OK to me too, but is there good return on complexity? Closing
>>> delimiter influence can also be used to opt out of stripping. Are there
>>> enough use-cases to justify a second opt-out mechanism? And does it have to
>>> be decided now, or could it be added later?
>>>
>>>
>>> --
>>> Kevin Bourrillion | Java Librarian | Google, Inc. | [email protected]
>>> <mailto:[email protected]>
>
>
>
> --
> Kevin Bourrillion | Java Librarian | Google, Inc. | [email protected]
> <mailto:[email protected]>
