[swift-evolution] multi-line string literals

[Chris Lattner]

> On Dec 14, 2015, at 12:35 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On Dec 10, 2015, at 11:07 PM, Travis Tilley <ttilley at gmail.com <mailto:ttilley at gmail.com>> wrote:
>> 
>> Chris - due to the complexity involved, would it make sense to have multiple proposals? One syntax need not fulfill the needs of every use case.
> 
> I’m not sure how to interpret this question.  Are you asking whether a proposal should start out simple, then have new things piled on top of it?  Or are you suggesting it would be better to have multiple new language features solving different problems?
> 
> In this case, my personal preference is to have a really well thought out long term vision for what we are doing in this space, and then subset the implementation to start with the simple pieces.  This avoids painting ourselves into a corner.  Further, I really hope we can avoid adding N new string literal syntaxes.  I see the existing one as the “simple” case, and the multiline case as the “advanced” case which can have knobs put on it for other advanced uses.

Catching up with the rest of this thread, here’s what I’d suggest:

- Please don’t extend simple “foo” strings to multiple lines.
- The ``` syntax is actually pretty interesting, I think that exploring it makes sense.  “”” doesn’t seem problematic to me though.
- Please consider ways that the string can have extensible options applied to it.  I haven’t thought much about this space, but the "String literal suffixes for defining types” has some interesting ideas (though using prefixes instead of suffixes seems appealing as was pointed out in some email). 
- I completely agree with Brent’s observation that we shouldn’t optimize for multi-line literals embedded into the middle of some other large expression.

The “configuration” aspect of this feature has come up several times.  It seems clear that the multi line literal has some obvious strong defaults: leading whitespace should be stripped, and escapes should be processed (including interpolation).  That said, being able to disable these independent of each other is important, and there are lots of other behaviors that can be considered as well.  I consider it a good thing for these behaviors to be explicit in the code.

As a strawman proposal (i.e. don’t take it seriously) to illustrate what I mean, you could use attributes for this, e.g. something like:

let foo = @disable_escape_processing ```
blah 
blah
 blah```

-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151214/415fbd9f/attachment.html>