[swift-evolution] multi-line string literals

[Paul Cantrell]

In the OP, Travis wrote:

> There is also the potential suggestion of removing consistent indentation if there is any so as to make formatting of a multi-line string literal look more clean when indented. 


Ruby has … oh, on the order of 2^9 different string syntaxes, but none of them address this indentation problem, and it’s a constant complaint. Hacks for it abound.

• • • 

In Ruby in the wild, off the top of my head and totally unscientifically, the most widely-used flavors I’ve seen are the heredoc with interpolation and terminator indentation:

    string = <<-EOS
      gone is music
      yet you sing
    EOS

…and just putting newlines inside a double-quoted string:

    string = "
      gone is music
      yet you sing
    "

…probably in that order.

Useful notes on the heredoc variants, typical of Ruby’s “the more syntaxes the merrier!” approach to things:

	http://blog.jayfields.com/2006/12/ruby-multiline-strings-here-doc-or.html

Cheers, P

> On Dec 10, 2015, at 11:02 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
> 
> On Dec 10, 2015, at 6:01 PM, Travis Tilley <ttilley at gmail.com <mailto:ttilley at gmail.com>> wrote:
>> 2) Should escapes like \n be processed always, should they never be processed, or should they be processed by default but disable-able in the syntax?
>> 
>> 
>> I would want multi-line string literals to behave as much like normal string literals as possible for consistency. To optimize for developer happiness, to steal the ruby saying, unexpected behavior should be kept to a minimum. If \n works in a normal string literal, it should work in a multi-line string literal... even if you could just hit enter instead.
> 
> Yes, I agree that should be the default.
> 
>> 3) What other policy decisions make sense to expose on these literals?  Since this will be the “powerful form of string literals”, it makes sense to be the place to put weird knobs that are seldom used but important in various cases.
>> 
>> 
>> ​I would have to depend entirely on you to inform me of both these knobs and use cases. ​I'd love to hear about them, that's for sure.
> 
> The reason I raise the question is that some languages have multiple quote styles (Perl 5 has something like 3 or 4 different string literal styles IIRC?) with different policies.  One reason for this is to disable processing of escapes: if you’re using string literals to enter something that uses \ or “ frequently, it can be irritating and ugly to have a lot of \\'s <smb://'s>.  In some dialects of inline assembly in C, for example, this can lead to very ugly code.
> 
> When introducing a feature like this, I think it would be useful to survey a range of popular languages (and yes, even perl ;-) to understand what facilities they provide and why (i.e. what problems they are solving) and synthesize a good swift design that can solve the same problems with a hopefully simple approach.
> 
> I haven’t looked into this area deeply myself, so I can’t give you a recipe to just follow, some research is required :)
> 
> 
>> My initial goal was the minimal possible work required to decrease the noise of writing large blocks of multi-line text and not have to poke around too much in the lexer and parser code (being completely unfamiliar with the swift codebase, having it just become open source recently).
> 
> Understood, but our first goal is to get the best solution, independent of implementation complexity.  In this case, I suspect that the hard part in this feature is scoping it out and hashing out the right design with the community.  I can’t imagine that we’d end up with a design that is that difficult to implement in any case.
> 
> -Chris
> 
> _______________________________________________
> 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/20151210/025274ff/attachment.html>