[swift-evolution] multi-line string literals

[Tyler Cloutier]

Also the concern about 

let x = “foo

would not be a problem with this proposal since only the currently line plus the new line character would be considered part of the String. The weird thing here is that this would be valid syntax and x would be “foo\n”. Which is not so good.

Tyler

> On Dec 14, 2015, at 1:50 PM, Tyler Cloutier via swift-evolution <swift-evolution at swift.org> wrote:
> 
> What about the following proposal, I’m afraid I don’t know if it’s possible to implement, but it really represents everything that I would like to see in a multiline String solution because it has no special syntax and the results are extremely straight forward and non-magical.
> 
> let x =
> "This is a proposal for a multiline literal String in Swift. This syntax solves a number of problems that
> "are common in other language's implementations of multiline Strings. This syntax is meant to be a
> "a generalization of regular Swift literal Strings, whereby a String is considered to begin with an open quote
> "and continue indefinitely until and including the end of the line (newline character),
> "or the String is closed with an ending quote.
> "
> "Firstly, indentation is now very clear and explicit. It is easy to see what the resulting string will be.
> "   This is one level of indentation.
> "       This is two levels.
> "
> "Secondly, there is no need for newline character processesing since it is well defined what newline behavior
> "should be.
> "
> "If a newline should be present in the code, but not in the resulting String it can be escaped with '\\' <smb://'> \
> " like so.
> "
> "Alternatively, perhaps that behavior could be left out and still accomplished by appending Strings in the
> " normal way with + or implicitly concatonated by the complier. Like so:
> " This is a long single line literal String. This is a long single line literal String. This is a long single"
> "line literal String."
> "
> "Thirdly, the indent level of these strings is decoupled from the indent level of the code, since there is a
>         "well defined starting point for the String on each line.
>     "   Thus you can indent the code and the string independently.
> "
> "Lastly, I don't actually know if this is even possible to implement. I don't know if these creates ambiguities
> "for the compiler, but it doesn't seem like it does at first glance.
> 
> This would require that adjacent Strings are automatically appended to each other by the compiler, (e.g. let x = “blah” “blah”, would be valid and x would equal “blahblah”. I don’t know how others would feel about something like this, but I’ve always wanted this behavior in multiline Strings. Perhaps I’ve forgotten some edge cases?
> 
> Tyler
> 
>> On Dec 14, 2015, at 12:47 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> 
>>> On Dec 14, 2015, at 12:35 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org <mailto: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
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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