Re: RFR: Multi-line String Literal (Preview) JEP [EG Draft]

> On May 15, 2019, at 12:11 PM, Alex Buckley wrote: > > On 5/15/2019 10:17 AM, Dan Smith wrote: >> I think this: >> >> ~~~ >> String code = """ >> public void print(""" + type + """ >>o) { >> System.out.println(Objects.toString(o)); >>

Re: RFR: Multi-line String Literal (Preview) JEP [EG Draft]

On 5/15/2019 10:17 AM, Dan Smith wrote: I think this: ~~~ String code = """ public void print(""" + type + """ o) { System.out.println(Objects.toString(o)); } """; ~~~ should be presented like this: ~~~ String

Re: RFR: Multi-line String Literal (Preview) JEP [EG Draft]

1/4. FTR, an escape <\ LT> could clean that up a bit more, if the goal is to get the interpolation cruft on a separate line: ~~~ String code = """ public void print(\ """ + type + """ o) { System.out.println(Objects.toString(o));

Re: RFR: Multi-line String Literal (Preview) JEP [EG Draft]

> Most of the examples in the JEP follow these rules as a convention already. > The concatenation examples would benefit from following it. Sorry, not seeing it — how would the concatenation examples benefit? Example?

Re: RFR: Multi-line String Literal (Preview) JEP [EG Draft]

> On May 13, 2019, at 8:05 AM, Jim Laskey wrote: > > After some significant tweaks, reopening the JEP for review. > https://bugs.openjdk.java.net/browse/JDK-8222530 > Something really clicks for me in calling these "text blocks". The delimiter

Re: RFR: Multi-line String Literal (Preview) JEP [EG Draft]

After some significant tweaks, reopening the JEP for review. https://bugs.openjdk.java.net/browse/JDK-8222530 The most significant change is the renaming to Text Blocks (I'm sure it will devolve over time Text Literals or just Texts.) This is

Re: RFR: Multi-line String Literal (Preview) JEP [EG Draft]

We have already discussed other conditions that can cause string literals to be rejected before the indentation stripper gets a crack at them. I see nothing wrong with stripIndent being a total function but also having the compiler filter string literals that appear in source code before the

Re: RFR: Multi-line String Literal (Preview) JEP [EG Draft]

> One possibility is language enforcement: at the part of the processing of a > multiline string where whitespace is stripped off to the left of the > rectangle, it could be an error if that leading whitespace is not “spelled > the same” on all lines from which it is being stripped. I lean

Re: RFR: Multi-line String Literal (Preview) JEP [EG Draft]

The nice thing about this rule is that having an editor/IDT _either_ detab _or_ retab should fix the problem. > On May 9, 2019, at 12:53 PM, Jim Laskey wrote: > > Reasonable. This is a learning step for new users of MLS. > > > >> On May 9, 2019, at 1:43 PM, Guy Steele >

Re: RFR: Multi-line String Literal (Preview) JEP [EG Draft]

Reasonable. This is a learning step for new users of MLS. > On May 9, 2019, at 1:43 PM, Guy Steele wrote: > > One possibility is language enforcement: at the part of the processing of a > multiline string where whitespace is stripped off to the left of the > rectangle, it could be an error

Re: RFR: Multi-line String Literal (Preview) JEP [EG Draft]

One possibility is language enforcement: at the part of the processing of a multiline string where whitespace is stripped off to the left of the rectangle, it could be an error if that leading whitespace is not “spelled the same” on all lines from which it is being stripped. I lean toward

Re: RFR: Multi-line String Literal (Preview) JEP [EG Draft]

Hello! Great draft, thank you. I'm especially happy that the expert group came to the conclusion that automatic builtin processing of the indentation is important. I proposed to do this in January, 2018 [1]. While the solution proposed in JEP draft is not as radical as proposed by me, I still