[swift-evolution] multi-line string literals

Dave Abrahams dabrahams at apple.com
Wed Dec 16 12:57:57 CST 2015


> On Dec 16, 2015, at 10:47 AM, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
> 
> On Dec 16, 2015, at 10:34 AM, Jordan Rose via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> IOW, 'x' where x must be a Character, that is, an extended Unicode
>>> grapheme cluster — represented in the source code as UTF8 or with the \u
>>> notation. A shortcut for typing Character("x").
>> 
>> We actually had this at one point, but it turned out that sometimes you wanted a Character and sometimes a UnicodeScalar, and in both cases your algorithm was probably wrong (cf. String is no longer a CollectionType). At that point it didn't offer any benefits over just regular string syntax, and it freed up the syntax for something else.
>> 
>> There's a fair amount of precedent for single-quoted strings being:
>> - single characters (C, Java, C#)
>> - unprocessed strings (shell scripts, Ruby)
>> - exactly the same as double-quoted strings (Python)
>> 
>> I (personally) wouldn't want them for multi-line literals, though.
> 
> I agree that this would be weird syntax for multi-line literals:
> 
> 
> let x = ‘
> stuff
> more stuff’
> 
> On the other hand, It could be a reasonable design to say that ‘xyz’ strings are a dual to “xyz” strings that disable escape expansion.  If you did that, then you could end up with a world where multi-line strings could be either:
> 
> let x = “””
> stuff with\tescapes \(42)
> “””
> 
> and:
> 
> let x = ‘''
> escapes\(42)not processed!\n
> ‘''
> 
> Please ignore the “smart” quotes above :-)

I said this during the Swift 1 runup, and I'll say it again: Python has a design for this stuff that works.  They didn't make any changes to it between Python 2 and 3, so it has proven itself with many generations of programmer. I still don't see any reason to invent something new. 

-Dave



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


More information about the swift-evolution mailing list