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. Yes, done.
So we have;
- Must have a line terminator after open delimiter.
- This allows the addition of directives (super escapes?) after
the open delimiter in the future
- Single line fat delimiter strings are illegal
- Close delimiter influence is used to control indentation.
- It is also used to degrees of opt out. Hard to the left
margin is 100% opt out.
Other notion mentioned;
- \<Line Terminator> eats the terminator and continues on the next line.
- I suppose we could have \<Space> to mean continue here
- This could effective provide margin control
-- Jim
> On Apr 25, 2019, at 9: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.
>
>
>> On Apr 25, 2019, at 8:19 PM, Kevin Bourrillion <kev...@google.com
>> <mailto: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
>> <mailto:cus...@google.com>> wrote:
>> On Thu, Apr 25, 2019 at 8:56 AM Brian Goetz <brian.go...@oracle.com
>> <mailto: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
>> <mailto:kev...@google.com>
