Wrapping up the first two courses

[Kevin Bourrillion]

On Thu, Apr 25, 2019 at 5:42 PM Brian Goetz <brian.goetz at 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.laskey at 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 <kevinb at 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 <cushon at google.com>
> wrote:
>
>> On Thu, Apr 25, 2019 at 8:56 AM Brian Goetz <brian.goetz at 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. | kevinb at google.com
>
>
>
>

-- 
Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20190426/9a53ee96/attachment-0001.html>