Wrapping up the first two courses

Jim Laskey james.laskey at oracle.com
Fri Apr 26 13:25:12 UTC 2019


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.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.
> 
> 
>> On Apr 25, 2019, at 8:19 PM, Kevin Bourrillion <kevinb at google.com <mailto: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 <mailto:cushon at google.com>> wrote:
>> On Thu, Apr 25, 2019 at 8:56 AM Brian Goetz <brian.goetz at oracle.com <mailto: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 <mailto:kevinb at google.com>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20190426/9a1f5e91/attachment.html>


More information about the amber-spec-experts mailing list