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 <cus...@google.com> wrote: > > On Wed, Mar 13, 2019 at 12:57 PM Brian Goetz <brian.go...@oracle.com > <mailto:brian.go...@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) > }
