String reboot (plain text)

[Brian Goetz]

I think all of this is fine in the context of a multi-line string feature (option 1a from my mail).  I think its highly questionable if we try to apply this to so-called “raw” string literals, and it becomes a tangled hairball if the _only_ way to get to the multi-line feature is to randomly suppress some forms of input processing (escapes) but not others (text reflow).  


> On Mar 15, 2019, at 2:49 PM, Liam Miller-Cushon <cushon at google.com> wrote:
> 
> On Wed, Mar 13, 2019 at 12:57 PM Brian Goetz <brian.goetz at oracle.com <mailto:brian.goetz at oracle.com>> wrote:
> To the “indent is good enough” point: Auto reflow is a disaster when applied to mixed spaces and tabs; while in general one should avoid this, I cannot rule out the possibility that someone might actually want to embed such a snippet; in that case, truly raw strings are an option.  If we take away truly raw, now they just have two bad approximations.
> 
> What do you think is the best framework for evaluating that trade-off?
> 
> The issues with leading spaces and tabs may be severe but should be extremely rare. The issues with manually managing leading indentation are less severe, but also very common.
> 
> If the leading indentation feature considers the closing delimiter position (as some of the earlier proposals did), it's easy to explicitly keep the leading whitespace and avoid collateral damage even with mixed spaces/tabs:
> 
>   void f() {
>     String hello = \"""
>         all leading whitespace is preserved
>         even with a mixture of tabs and spaces
> """\; // (the closing delimiter is un-indented to the margin, forcing leading whitespace to be kept for the other lines)
>   }

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