Yes, that’s the sort of thing I have in mind.
The sequence / + LT + (blanks)* would be replaced by the null string when
escapes are processed and *after* rectangle extraction.
Any space before the / would be left untouched, since it’s not part of the
escape sequence. This gives a hook for breaking up long lines and rejoining
them as payload either with or without intervening spaces.
The +(spaces)* part above is not strictly necessary but it plays well with the
other parts of the syntax, allowing users additional freedom to lay out their
program readably. Readability being, of course, more important than
writability.
> On Apr 26, 2019, at 8:54 AM, Jim Laskey <james.las...@oracle.com> wrote:
>
> 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 <kev...@google.com> wrote:
>>
>>> On Thu, Apr 25, 2019 at 5:42 PM Brian Goetz <brian.go...@oracle.com> 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 <james.las...@oracle.com> 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 <kev...@google.com> 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 <cus...@google.com>
>>>>>> wrote:
>>>>>> On Thu, Apr 25, 2019 at 8:56 AM Brian Goetz <brian.go...@oracle.com>
>>>>>> 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. | kev...@google.com
>>>>
>>>
>>
>>
>> --
>> Kevin Bourrillion | Java Librarian | Google, Inc. | kev...@google.com
>
