# Optional dictionary subscripts **URL:** \ **Category:** Discussion\ **Created:** [December 22, 2015, 11:37am UTC](https://forums.swift.org/t/optional-dictionary-subscripts/719 "2015-12-22T11:37:54Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![johnno1962](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/johnno1962/32/6805_2.png) [@johnno1962](https://forums.swift.org/u/johnno1962)\ **Post date:** [December 22, 2015, 11:37am UTC](https://forums.swift.org/t/optional-dictionary-subscripts/719/1 "2015-12-22T11:37:54Z")
This isn’t the most compelling of ideas but a couple of times I’ve found myself writing: if let value = key != nil ? dict[key] : nil {… and was wondering if the syntax could be: if let value = dict[key?] {… The key for dictionaries could be made optional in stdlib but this is probably best implemented in the compiler for safety. Cheers ---
**Author:** ![Erica\_Sadun](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/erica_sadun/32/243_2.png) [@Erica\_Sadun](https://forums.swift.org/u/Erica_Sadun)\ **Post date:** [December 22, 2015, 6:00pm UTC](https://forums.swift.org/t/optional-dictionary-subscripts/719/2 "2015-12-22T18:00:45Z")
if let key = key, value = dict[key] {     ...whatever... } seems to work fine without introducing a new construct -- E, waving hi to John > **···** > > > On Dec 22, 2015, at 4:37 AM, John Holdsworth via swift-evolution \ wrote: > > > > This isn’t the most compelling of ideas but a couple of times I’ve found myself writing: > > > > if let value = key != nil ? dict[key] : nil {… > > > > and was wondering if the syntax could be: > > > > if let value = dict[key?] {… > > > > The key for dictionaries could be made optional in stdlib but this is probably best implemented in the compiler for safety. > > > > Cheers > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![Felix\_Cloutier1](https://avatars.discourse-cdn.com/v4/letter/f/e47c2d/32.png) [@Felix\_Cloutier1](https://forums.swift.org/u/Felix_Cloutier1)\ **Post date:** [December 22, 2015, 6:33pm UTC](https://forums.swift.org/t/optional-dictionary-subscripts/719/3 "2015-12-22T18:33:58Z")
if let value = map(key) { dict($0) } Félix > **···** > > > Le 22 déc. 2015 à 13:00:45, Erica Sadun via swift-evolution \ a écrit : > > > > if let key = key, value = dict[key] { > >    ...whatever... > > } > > > > seems to work fine without introducing a new construct > > > > -- E, waving hi to John > > > > > On Dec 22, 2015, at 4:37 AM, John Holdsworth via swift-evolution \ wrote: > > > > > > This isn’t the most compelling of ideas but a couple of times I’ve found myself writing: > > > > > > if let value = key != nil ? dict[key] : nil {… > > > > > > and was wondering if the syntax could be: > > > > > > if let value = dict[key?] {… > > > > > > The key for dictionaries could be made optional in stdlib but this is probably best implemented in the compiler for safety. > > > > > > Cheers > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > swift-evolution mailing list > > > swift-evolution@swift.org > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![johnno1962](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/johnno1962/32/6805_2.png) [@johnno1962](https://forums.swift.org/u/johnno1962)\ **Post date:** [April 22, 2016, 4:59pm UTC](https://forums.swift.org/t/optional-dictionary-subscripts/719/4 "2016-04-22T16:59:04Z")
I’ve raised a speculative PR against the Swift Lexer to support multi-line string literals as was suggested in the very first week Swift was open sourced and before that in various radars. > > > \#### What's in this pull request? > > This PR is a proof of concept picking up a no…t yet formally proposed evolution to have Swift support multi-line string literals after the python “””string””” syntax. > > Changes to Lexer.cpp are very minor and the remainder of the toolchain seems unfazed with testing showing the following functioning correctly: Xcode Source Editor, syntax highlighting, compilation errors and their line numbers, breakpoints (even inside the string), value interpolation, accurate crash site reporting and, SourceKit’s indenting code is not affected. > > !\[multiline\](https://cloud.githubusercontent.com/assets/1786033/14742381/de12889e-0893-11e6-9560-b00e8eceff47.png) > > To keep documentation straightforward and to confine the change to the lexer, no attempt has been made to remove the first newline from the string or deal with removing indenting in the string which were mentioned as potential desirables in the following thread: > > https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001565.html > > If this approach seems acceptable, let me know and I’ll create a full evolution proposal so this can be discussed by the community. > \#### Resolved bug number: > > https://bugs.swift.org/browse/SR-170 The approach taken is as simple as possible defining multi-line strings as being delimited by “”” instead of “ and thereafter able to contain new line characters. There has been some discussion of this before on swift-evolution: [https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001565.html](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001565.html) I’m trying to avoid more advanced features such as the handling of indenting which for me complicates something that if kept simple can be documented very easily. This change will require a evolution proposal so I’d like to take the pulse before I write it up. Thoughts? John ---
**Author:** ![dabrahams](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/dabrahams/32/9815_2.png) [@dabrahams](https://forums.swift.org/u/dabrahams)\ **Post date:** [December 23, 2015, 1:43am UTC](https://forums.swift.org/t/optional-dictionary-subscripts/719/5 "2015-12-23T01:43:03Z")
I think this would be the standard syntax: if let value = key.map({ dict[$0] }) { } > **···** > > > On Dec 22, 2015, at 10:33 AM, Félix Cloutier via swift-evolution \ wrote: > > > > if let value = map(key) { dict($0) } > > > > Félix > > > > > Le 22 déc. 2015 à 13:00:45, Erica Sadun via swift-evolution \ a écrit : > > > > > > if let key = key, value = dict[key] { > > >   ...whatever... > > > } > > > > > > seems to work fine without introducing a new construct > > > > > > -- E, waving hi to John > > > > > > > On Dec 22, 2015, at 4:37 AM, John Holdsworth via swift-evolution \ wrote: > > > > > > > > This isn’t the most compelling of ideas but a couple of times I’ve found myself writing: > > > > > > > > if let value = key != nil ? dict[key] : nil {… > > > > > > > > and was wondering if the syntax could be: > > > > > > > > if let value = dict[key?] {… > > > > > > > > The key for dictionaries could be made optional in stdlib but this is probably best implemented in the compiler for safety. > > > > > > > > Cheers > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > > swift-evolution mailing list > > > > swift-evolution@swift.org > > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > swift-evolution mailing list > > > swift-evolution@swift.org > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > -Dave ---
**Author:** ![Patrick\_Gili](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/patrick_gili/32/6033_2.png) [@Patrick\_Gili](https://forums.swift.org/u/Patrick_Gili)\ **Post date:** [April 22, 2016, 6:12pm UTC](https://forums.swift.org/t/optional-dictionary-subscripts/719/6 "2016-04-22T18:12:22Z")
This doesn't provide very much flexibility. I'd like to see something more like Perl6's quoting constructs: [GitHub - Raku/old-design-docs: Raku language design documents](https://doc.perl6.org/language/quoting%5C). -Patrick > **···** > > > On Apr 22, 2016, at 12:59 PM, John Holdsworth via swift-evolution \ wrote: > > > > I’ve raised a speculative PR against the Swift Lexer to support multi-line string literals as was > > suggested in the very first week Swift was open sourced and before that in various radars. > > > > [[Parse] Adjust Lexer to allow Multi-line string literals by johnno1962 · Pull Request #2275 · apple/swift · GitHub](https://github.com/apple/swift/pull/2275) > > > > The approach taken is as simple as possible defining multi-line strings as being > > delimited by “”” instead of “ and thereafter able to contain new line characters. > > > > There has been some discussion of this before on swift-evolution: > > > > [[swift-evolution] multi-line string literals](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001565.html) > > > > I’m trying to avoid more advanced features such as the handling of indenting which > > for me complicates something that if kept simple can be documented very easily. > > > > This change will require a evolution proposal so I’d like to take the pulse before I write it up. > > > > Thoughts? > > > > John > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![johnno1962](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/johnno1962/32/6805_2.png) [@johnno1962](https://forums.swift.org/u/johnno1962)\ **Post date:** [April 22, 2016, 6:48pm UTC](https://forums.swift.org/t/optional-dictionary-subscripts/719/7 "2016-04-22T18:48:28Z")
As a long time user of Perl, for me the simplicity and lack of flexibility is the attraction when it comes to “”” syntax ;) That’s a lot of documentation for just specifying a string. Perl makes life difficult for itself due to it’s rather simplistic $var interpolation syntax which means you frequently want an un-interpolated string literal. The situation is far better in Swift with the more distinct \(). Can you think of anything that couldn’t be readily expressed using Python style “””? John > **···** > > > On 22 Apr 2016, at 19:12, Patrick Gili \ wrote: > > > > This doesn't provide very much flexibility. I'd like to see something more like Perl6's quoting constructs: [https://doc.perl6.org/language/quoting\](https://doc.perl6.org/language/quoting%5C). > > > > -Patrick > > > > > On Apr 22, 2016, at 12:59 PM, John Holdsworth via swift-evolution \ wrote: > > > > > > I’ve raised a speculative PR against the Swift Lexer to support multi-line string literals as was > > > suggested in the very first week Swift was open sourced and before that in various radars. > > > > > > [[Parse] Adjust Lexer to allow Multi-line string literals by johnno1962 · Pull Request #2275 · apple/swift · GitHub](https://github.com/apple/swift/pull/2275) > > > > > > The approach taken is as simple as possible defining multi-line strings as being > > > delimited by “”” instead of “ and thereafter able to contain new line characters. > > > > > > There has been some discussion of this before on swift-evolution: > > > > > > [[swift-evolution] multi-line string literals](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001565.html) > > > > > > I’m trying to avoid more advanced features such as the handling of indenting which > > > for me complicates something that if kept simple can be documented very easily. > > > > > > This change will require a evolution proposal so I’d like to take the pulse before I write it up. > > > > > > Thoughts? > > > > > > John > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > swift-evolution mailing list > > > swift-evolution@swift.org > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![Brent\_Royal-Gordon](https://avatars.discourse-cdn.com/v4/letter/b/53a042/32.png) [@Brent\_Royal-Gordon](https://forums.swift.org/u/Brent_Royal-Gordon)\ **Post date:** [April 23, 2016, 9:08pm UTC](https://forums.swift.org/t/optional-dictionary-subscripts/719/8 "2016-04-23T21:08:11Z")
> I’ve raised a speculative PR against the Swift Lexer to support multi-line string literals Wow, it's pretty cool that this change is so surgical. > I’m trying to avoid more advanced features such as the handling of indenting which > for me complicates something that if kept simple can be documented very easily. I don't think you can tackle multiline strings without worrying about indenting. Indentation may fundamentally change the approach you choose. I continue to believe that we're actually looking at three orthogonal features here: \* Multiline string literals \* Alternative string literal delimiters \* Disabling escapes in string literals The way I would prefer to tackle these is: \* Multiline literals: If the closing quote of a string is not present, look at the next line. If it consists of (optional) indentation followed by a matching opening quote, the string has a newline and then continues after the quote on the next line. (The handling of comments is an open question here.)   let xml: String = "\         "\         "\t\         "\t\t\\(author)\         "\t\         "\" The cool things about this are that (a) the compiler can tell you really do mean this to be part of the literal and you haven't just forgotten to close the string, and (b) there's no guesswork about how indentation should be handled. The uncool thing is that you need to insert the quote at the beginning of each line, so you can't just blindly paste into a multiline literal. Editors can help make that easier, though—a "paste as string literal" feature would be a nice addition to Xcode, and not just for multiline strings or just for Swift. \* Alternative delimiters: If a string literal starts with three, or five, or seven, or etc. quotes, that is the delimiter, and fewer quotes than that in a row are simply literal quote marks. Four, six, etc. quotes is a quote mark abutting the end of the literal.   let xml: String = """\         """\         """\t\         """\t\t\\(author)\         """\t\         """\""" You can't use this syntax to express an empty string, or a string consisting entirely of quote marks, but `""` handles empty strings adequately, and escaping can help with quote marks. (An alternative would be to remove the abutting rule and permit `""""""` to mean "empty string", but abutting quotes seem more useful than long-delimiter empty strings.) \* Disabling escapes: If you use single quotes instead of double quotes, backslash escapes are disabled. (There is no escaping at all, not even \\ or \'. If you need to include the delimiter, use a delimiter with more quote marks. I'm not sure if this should disable interpolation; for now, I'm assuming it should. If it doesn't disable interpolation, the only way to get a \( into the string would be by interpolating it in, not by escaping it somehow.)   let xml: String = '''\         '''\         ''' \         ''' \''' + author + '''\         ''' \         '''\''' I'm not sure if single quotes should allow interpolation. Options are: \* No, just concatenate (as shown above). \* Yes, with the ordinary syntax: ''' \\(author)\ \* Yes, with a number of backslashes matching the number of quotes, which allows you to insert literal \( text: ''' \\\\(author)\ Note that you can use these features in any combination. I've shown a few combinations above, but here are some others. A single-line literal with an alternate delimiter:   """ \""" The same thing, but no-escaping:   ''' \''' A no-escaping multiline literal with a normal delimiter:   '\   '\' \* \* \* Notes on alternatives: 1. If you wanted to not provide no-escaping strings, an alternative would be to say that \*all\* escapes require as many backslashes as there are quotes in the string delimiter. Thus, a newline escape in a `"""` string would be `\\\n`. This would in practice give you the same flexibility to write a literal without worrying (much) about escaping. 2. However, it's not entirely clear to me that we really need escapes other than interpolations at all. You could write "\(.newline)" or "\(.doubleQuote)" or "\(.backslash)" to get those characters. (These might be static members required by StringInterpolationConvertible.) Plain backslashes would have no special meaning at all; only "\(" would be special. 3. It might be useful to make multiline `"` strings trim trailing whitespace and comments like Perl's `/x` regex modifier does. That would allow you to document things in literals. Then you would want `'` again so that you could turn that smartness off. (Of course, the big problem here is that a naïve implementation would consider "http://" to have a comment at the end of it.) \* \* \* Finally, a brief aside: > For example, a regular expression that detects a might be written "\N\*\n". If escaping is enabled, then the compiler changes "\n" into line feed, which does not have the same meaning to the regular expression engine as "\n". There is a special place in Hell reserved for authors of languages which use `\` as an escape character, provide no regex literals or non-escaping string literals, and ship with regex libraries which use `\` as a metacharacter. It's in the outer circles—Satan has some sense of perspective—but it's definitely there. Sorry if that's not very constructive, but \*man\*, that burns my biscuits. > **···** > > -- > Brent Royal-Gordon > Architechies ---
**Author:** ![Uli\_Kusterer](https://avatars.discourse-cdn.com/v4/letter/u/838e76/32.png) [@Uli\_Kusterer](https://forums.swift.org/u/Uli_Kusterer)\ **Post date:** [April 27, 2016, 1:22am UTC](https://forums.swift.org/t/optional-dictionary-subscripts/719/9 "2016-04-27T01:22:27Z")
Just ignore me if that's been covered in the archives already (there is a lot there, I'm still catching up), but is there a reason we can't just allow newlines in the existing string constants and be done with it? Since they've been invalid so far, nobody has code that contains line breaks that could be broken. At worst the code formatter would have to be told not to indent such lines, but beyond that, why are newlines in strings not permitted? Cheers, -- Uli Kusterer "The Witnesses of TeachText are everywhere..." > **[Home](https://stacksmith.org/)** > > Stacksmith - A tool for making apps for non-programmers. > **···** > > On 22 Apr 2016, at 18:59, John Holdsworth via swift-evolution \ wrote: > > > [[Parse] Adjust Lexer to allow Multi-line string literals by johnno1962 · Pull Request #2275 · apple/swift · GitHub](https://github.com/apple/swift/pull/2275) > > > > The approach taken is as simple as possible defining multi-line strings as being > > delimited by “”” instead of “ and thereafter able to contain new line characters. ---
**Author:** ![Brent\_Royal-Gordon](https://avatars.discourse-cdn.com/v4/letter/b/53a042/32.png) [@Brent\_Royal-Gordon](https://forums.swift.org/u/Brent_Royal-Gordon)\ **Post date:** [December 23, 2015, 9:21am UTC](https://forums.swift.org/t/optional-dictionary-subscripts/719/10 "2015-12-23T09:21:56Z")
> I think this would be the standard syntax: > > if let value = key.map({ dict[$0] }) { > > } In this case, I think you actually want a flatMap, to merge the two `nil` cases instead of nesting them.   if let value = key.flatMap({ dict[$0] }) {        } I wish that could be this, though:   if let value = key.flatMap(dict.subscript) {        } In any case, I think two different approaches to do this (chained `if let` and `flatMap`) are probably enough; we don't need a third. > **···** > > -- > Brent Royal-Gordon > Architechies ---
**Author:** ![Kurt\_Werle](https://avatars.discourse-cdn.com/v4/letter/k/a587f6/32.png) [@Kurt\_Werle](https://forums.swift.org/u/Kurt_Werle)\ **Post date:** [April 22, 2016, 6:57pm UTC](https://forums.swift.org/t/optional-dictionary-subscripts/719/11 "2016-04-22T18:57:17Z")
+1 > **···** > > On Fri, Apr 22, 2016 at 11:48 AM, John Holdsworth via swift-evolution \< swift-evolution@swift.org\> wrote: > > > As a long time user of Perl, for me the simplicity and lack of flexibility > > is the attraction > > when it comes to “”” syntax ;) That’s a lot of documentation for just > > specifying a string. > > -- > kurt@CircleW.org > [http://www.CircleW.org/kurt/](http://www.CircleW.org/kurt/) ---
**Author:** ![Patrick\_Gili](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/patrick_gili/32/6033_2.png) [@Patrick\_Gili](https://forums.swift.org/u/Patrick_Gili)\ **Post date:** [April 22, 2016, 7:54pm UTC](https://forums.swift.org/t/optional-dictionary-subscripts/719/12 "2016-04-22T19:54:51Z")
If we use a quoting structure similar to Perl6, then we future proof the grammar to accommodate regular expression literals (and multi-line regular expression literals) later. It also gives us the possibility for support for fine-grain control over escaping and interpolation. -Patrick > **···** > > > On Apr 22, 2016, at 2:48 PM, John Holdsworth \ wrote: > > > > As a long time user of Perl, for me the simplicity and lack of flexibility is the attraction > > when it comes to “”” syntax ;) That’s a lot of documentation for just specifying a string. > > > > Perl makes life difficult for itself due to it’s rather simplistic $var interpolation syntax > > which means you frequently want an un-interpolated string literal. The situation is > > far better in Swift with the more distinct \(). > > > > Can you think of anything that couldn’t be readily expressed using Python style “””? > > > > John > > > > > On 22 Apr 2016, at 19:12, Patrick Gili \ wrote: > > > > > > This doesn't provide very much flexibility. I'd like to see something more like Perl6's quoting constructs: [GitHub - Raku/old-design-docs: Raku language design documents](https://doc.perl6.org/language/quoting%5C). > > > > > > -Patrick > > > > > > > On Apr 22, 2016, at 12:59 PM, John Holdsworth via swift-evolution \ wrote: > > > > > > > > I’ve raised a speculative PR against the Swift Lexer to support multi-line string literals as was > > > > suggested in the very first week Swift was open sourced and before that in various radars. > > > > > > > > [[Parse] Adjust Lexer to allow Multi-line string literals by johnno1962 · Pull Request #2275 · apple/swift · GitHub](https://github.com/apple/swift/pull/2275) > > > > > > > > The approach taken is as simple as possible defining multi-line strings as being > > > > delimited by “”” instead of “ and thereafter able to contain new line characters. > > > > > > > > There has been some discussion of this before on swift-evolution: > > > > > > > > [[swift-evolution] multi-line string literals](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001565.html) > > > > > > > > I’m trying to avoid more advanced features such as the handling of indenting which > > > > for me complicates something that if kept simple can be documented very easily. > > > > > > > > This change will require a evolution proposal so I’d like to take the pulse before I write it up. > > > > > > > > Thoughts? > > > > > > > > John > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > > swift-evolution mailing list > > > > swift-evolution@swift.org > > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![johnno1962](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/johnno1962/32/6805_2.png) [@johnno1962](https://forums.swift.org/u/johnno1962)\ **Post date:** [April 23, 2016, 3:13am UTC](https://forums.swift.org/t/optional-dictionary-subscripts/719/13 "2016-04-23T03:13:38Z")
Regex support certainly needs to be kept in mind. I can propose something a little different on that front however that retains the existing simple literal syntax. Bear with me. What if invalid escape sequences did not result in an error but were passed through to the string? This is a very small change to the lexer. For example: > print( “\w+[\w\d]+” ) \w+[\w\d]+ It’s easy for a developer to know there are only seven valid escapes \0, \r, \n, \”, \’, \\ and \u{NNNN} so the error is not a particularly helpful one and these escapes do not overlap with regex syntax. In this way you get the best of both worlds, minimalist string syntax and not have to write “\\w+[\\w\\d]+” John > **···** > > > On 22 Apr 2016, at 20:54, Patrick Gili \ wrote: > > > > If we use a quoting structure similar to Perl6, then we future proof the grammar to accommodate regular expression literals (and multi-line regular expression literals) later. It also gives us the possibility for support for fine-grain control over escaping and interpolation. > > > > -Patrick > > > > > On Apr 22, 2016, at 2:48 PM, John Holdsworth \ wrote: > > > > > > As a long time user of Perl, for me the simplicity and lack of flexibility is the attraction > > > when it comes to “”” syntax ;) That’s a lot of documentation for just specifying a string. > > > > > > Perl makes life difficult for itself due to it’s rather simplistic $var interpolation syntax > > > which means you frequently want an un-interpolated string literal. The situation is > > > far better in Swift with the more distinct \(). > > > > > > Can you think of anything that couldn’t be readily expressed using Python style “””? > > > > > > John > > > > > > > On 22 Apr 2016, at 19:12, Patrick Gili \ wrote: > > > > > > > > This doesn't provide very much flexibility. I'd like to see something more like Perl6's quoting constructs: [GitHub - Raku/old-design-docs: Raku language design documents](https://doc.perl6.org/language/quoting%5C). > > > > > > > > -Patrick > > > > > > > > > On Apr 22, 2016, at 12:59 PM, John Holdsworth via swift-evolution \ wrote: > > > > > > > > > > I’ve raised a speculative PR against the Swift Lexer to support multi-line string literals as was > > > > > suggested in the very first week Swift was open sourced and before that in various radars. > > > > > > > > > > [[Parse] Adjust Lexer to allow Multi-line string literals by johnno1962 · Pull Request #2275 · apple/swift · GitHub](https://github.com/apple/swift/pull/2275) > > > > > > > > > > The approach taken is as simple as possible defining multi-line strings as being > > > > > delimited by “”” instead of “ and thereafter able to contain new line characters. > > > > > > > > > > There has been some discussion of this before on swift-evolution: > > > > > > > > > > [[swift-evolution] multi-line string literals](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001565.html) > > > > > > > > > > I’m trying to avoid more advanced features such as the handling of indenting which > > > > > for me complicates something that if kept simple can be documented very easily. > > > > > > > > > > This change will require a evolution proposal so I’d like to take the pulse before I write it up. > > > > > > > > > > Thoughts? > > > > > > > > > > John > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > > > swift-evolution mailing list > > > > > swift-evolution@swift.org > > > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![Michael\_Peternell](https://avatars.discourse-cdn.com/v4/letter/m/bc79bd/32.png) [@Michael\_Peternell](https://forums.swift.org/u/Michael_Peternell)\ **Post date:** [April 23, 2016, 9:37pm UTC](https://forums.swift.org/t/optional-dictionary-subscripts/719/14 "2016-04-23T21:37:51Z")
Instead of creating yet another set of string quotation rules, I would prefer copy & pasting the Perl 5 rules :) let x = XMLDocument(\<\   \it works\ \ END\_OF\_XML /\* I think multiline literals should not consider indentation. If you want to have it formatted nicely, the editor should display a nice text box for you. Editors could do so much more than they are doing now, IMHO. I remember a time when editors refused to interoperate, because one file used a LF line style, while another editor used CRLF. Now, this is no longer a problem, and the reasons are better editors. Editors could also solve the Tabs- versus Spaces-issues or the { bracket styles }, by always keeping the style of the file intact, but displaying the style that the user likes to see. \*/ let y = q(if you want to use " and ' and even """ in the string itself. You can also use (parenthesis), as long as you balance them properly. A single "q" at the beginning, so no string interpolation here.) let z = qq/if you want string interpolation, you can have it. BTW x = $(x)/ let w: Array\ = qw[this is an array of words] m/regexes are a nice feature too/i s{if you want to match slashes\(/\), just use another delimiter.}{yes, we can}g -Michael > **···** > > > Am 23.04.2016 um 23:08 schrieb Brent Royal-Gordon via swift-evolution \: > > > > > I’ve raised a speculative PR against the Swift Lexer to support multi-line string literals > > > > Wow, it's pretty cool that this change is so surgical. > > > > > I’m trying to avoid more advanced features such as the handling of indenting which > > > for me complicates something that if kept simple can be documented very easily. > > > > I don't think you can tackle multiline strings without worrying about indenting. Indentation may fundamentally change the approach you choose. > > > > I continue to believe that we're actually looking at three orthogonal features here: > > > > \* Multiline string literals > > \* Alternative string literal delimiters > > \* Disabling escapes in string literals > > > > The way I would prefer to tackle these is: > > > > \* Multiline literals: If the closing quote of a string is not present, look at the next line. If it consists of (optional) indentation followed by a matching opening quote, the string has a newline and then continues after the quote on the next line. (The handling of comments is an open question here.) > > > >   let xml: String = "\ > >         "\ > >         "\t\ > >         "\t\t\\(author)\ > >         "\t\ > >         "\" > > > > The cool things about this are that (a) the compiler can tell you really do mean this to be part of the literal and you haven't just forgotten to close the string, and (b) there's no guesswork about how indentation should be handled. The uncool thing is that you need to insert the quote at the beginning of each line, so you can't just blindly paste into a multiline literal. Editors can help make that easier, though—a "paste as string literal" feature would be a nice addition to Xcode, and not just for multiline strings or just for Swift. > > > > \* Alternative delimiters: If a string literal starts with three, or five, or seven, or etc. quotes, that is the delimiter, and fewer quotes than that in a row are simply literal quote marks. Four, six, etc. quotes is a quote mark abutting the end of the literal. > > > >   let xml: String = """\ > >         """\ > >         """\t\ > >         """\t\t\\(author)\ > >         """\t\ > >         """\""" > > > > You can't use this syntax to express an empty string, or a string consisting entirely of quote marks, but `""` handles empty strings adequately, and escaping can help with quote marks. (An alternative would be to remove the abutting rule and permit `""""""` to mean "empty string", but abutting quotes seem more useful than long-delimiter empty strings.) > > > > \* Disabling escapes: If you use single quotes instead of double quotes, backslash escapes are disabled. (There is no escaping at all, not even \\ or \'. If you need to include the delimiter, use a delimiter with more quote marks. I'm not sure if this should disable interpolation; for now, I'm assuming it should. If it doesn't disable interpolation, the only way to get a \( into the string would be by interpolating it in, not by escaping it somehow.) > > > >   let xml: String = '''\ > >         '''\ > >         ''' \ > >         ''' \''' + author + '''\ > >         ''' \ > >         '''\''' > > > > I'm not sure if single quotes should allow interpolation. Options are: > > > > \* No, just concatenate (as shown above). > > \* Yes, with the ordinary syntax: ''' \\(author)\ > > \* Yes, with a number of backslashes matching the number of quotes, which allows you to insert literal \( text: ''' \\\\(author)\ > > > > Note that you can use these features in any combination. I've shown a few combinations above, but here are some others. > > > > A single-line literal with an alternate delimiter: > >   """ \""" > > > > The same thing, but no-escaping: > >   ''' \''' > > > > A no-escaping multiline literal with a normal delimiter: > >   '\ > >   '\' > > > > \* \* \* > > > > Notes on alternatives: > > > > 1. If you wanted to not provide no-escaping strings, an alternative would be to say that \*all\* escapes require as many backslashes as there are quotes in the string delimiter. Thus, a newline escape in a `"""` string would be `\\\n`. This would in practice give you the same flexibility to write a literal without worrying (much) about escaping. > > > > 2. However, it's not entirely clear to me that we really need escapes other than interpolations at all. You could write "\(.newline)" or "\(.doubleQuote)" or "\(.backslash)" to get those characters. (These might be static members required by StringInterpolationConvertible.) Plain backslashes would have no special meaning at all; only "\(" would be special. > > > > 3. It might be useful to make multiline `"` strings trim trailing whitespace and comments like Perl's `/x` regex modifier does. That would allow you to document things in literals. Then you would want `'` again so that you could turn that smartness off. (Of course, the big problem here is that a naïve implementation would consider "http://" to have a comment at the end of it.) > > > > \* \* \* > > > > Finally, a brief aside: > > > > > For example, a regular expression that detects a might be written "\N\*\n". If escaping is enabled, then the compiler changes "\n" into line feed, which does not have the same meaning to the regular expression engine as "\n". > > > > There is a special place in Hell reserved for authors of languages which use `\` as an escape character, provide no regex literals or non-escaping string literals, and ship with regex libraries which use `\` as a metacharacter. It's in the outer circles—Satan has some sense of perspective—but it's definitely there. > > > > Sorry if that's not very constructive, but \*man\*, that burns my biscuits. > > > > -- > > Brent Royal-Gordon > > Architechies > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![Chris\_Lattner](https://avatars.discourse-cdn.com/v4/letter/c/bc8723/32.png) [@Chris\_Lattner](https://forums.swift.org/u/Chris_Lattner)\ **Post date:** [April 24, 2016, 10:09pm UTC](https://forums.swift.org/t/optional-dictionary-subscripts/719/15 "2016-04-24T22:09:58Z")
Wouldn’t the natural regex literal syntax be to enclose them in /’s, e.g. /foo\*/ ? I don’t see how this proposal conflicts with that. -Chris > **···** > > On Apr 22, 2016, at 12:54 PM, Patrick Gili via swift-evolution \ wrote: > > > If we use a quoting structure similar to Perl6, then we future proof the grammar to accommodate regular expression literals (and multi-line regular expression literals) later. It also gives us the possibility for support for fine-grain control over escaping and interpolation. ---
**Author:** ![Chris\_Lattner](https://avatars.discourse-cdn.com/v4/letter/c/bc8723/32.png) [@Chris\_Lattner](https://forums.swift.org/u/Chris_Lattner)\ **Post date:** [April 24, 2016, 10:35pm UTC](https://forums.swift.org/t/optional-dictionary-subscripts/719/16 "2016-04-24T22:35:14Z")
> > I’m trying to avoid more advanced features such as the handling of indenting which > > for me complicates something that if kept simple can be documented very easily. > > I don't think you can tackle multiline strings without worrying about indenting. Indentation may fundamentally change the approach you choose. I agree with this and almost every point you make in your email (and your other subsequent one about one approach maximally general). That said, I wonder if there is a different conclusion that can be reached. I’m going to rearrange your three features a bit: > The way I would prefer to tackle these is: > > \* Multiline literals: If the closing quote of a string is not present, look at the next line. If it consists of (optional) indentation followed by a matching opening quote, the string has a newline and then continues after the quote on the next line. (The handling of comments is an open question here.) > >   let xml: String = "\ >         "\ >         "\t\ >         "\t\t\\(author)\ >         "\t\ >         "\" > > The cool things about this are that (a) the compiler can tell you really do mean this to be part of the literal and you haven't just forgotten to close the string, and (b) there's no guesswork about how indentation should be handled. The uncool thing is that you need to insert the quote at the beginning of each line, so you can't just blindly paste into a multiline literal. Editors can help make that easier, though—a "paste as string literal" feature would be a nice addition to Xcode, and not just for multiline strings or just for Swift. Yes, I completely agree. This is is awesome, and a nice & simple generalization of our existing syntax. It has obvious behavior even if you encounter it in code without knowing about the feature. > \* Disabling escapes: If you use single quotes instead of double quotes, backslash escapes are disabled. We need a way to disable escapes, but it seems to me that (since it is orthogonal to the other concerns) that it should not be tied to the “multiple single quotes” syntax. What is your thought on “modifier” prefix characters for string literals? e.g.:   let x = e”no \escapes \(processed here” If we supported these, they would be supported with multi-line string literals by putting the modifiers on the first line of the literal, and the multi-line approach above would “just work”. You could introduce several different modifiers, e.g. one that disabled general escapes, but still allowed \(x) for substitution. > \* Yes, with a number of backslashes matching the number of quotes, which allows you to insert literal \( text: ''' \\\\(author)\ Egads! > Notes on alternatives: > > 1. If you wanted to not provide no-escaping strings, an alternative would be to say that \*all\* escapes require as many backslashes as there are quotes in the string delimiter. Thus, a newline escape in a `"""` string would be `\\\n`. This would in practice give you the same flexibility to write a literal without worrying (much) about escaping. I’m really not a fan of requiring “stacking” of escapes to re-enable them. This (IMO) just makes it less likely that you’ll run into an edge case. I also don’t like the “fix" being to have to use 5 quotes around your strings :-) > 3. It might be useful to make multiline `"` strings trim trailing whitespace and comments like Perl's `/x` regex modifier does. If you have modifier characters already, it is easy to build a small zoo full of these useful beasts. > \* Alternative delimiters: If a string literal starts with three, or five, or seven, or etc. quotes, that is the delimiter, and fewer quotes than that in a row are simply literal quote marks. Four, six, etc. quotes is a quote mark abutting the end of the literal. > >   let xml: String = """\ >         """\ >         """\t\ >         """\t\t\\(author)\ >         """\t\ >         """\""" > > You can't use this syntax to express an empty string, or a string consisting entirely of quote marks, but `""` handles empty strings adequately, and escaping can help with quote marks. (An alternative would be to remove the abutting rule and permit `""""""` to mean "empty string", but abutting quotes seem more useful than long-delimiter empty strings.) I agree that there is a need to support alternative delimiters, but subjectively, I find this to be pretty ugly. It is also a really unfortunate degenerate case for “I just want a large blob of XML” because you’d end up using “"” almost all the time, and you have to use it on every line. For cases like this, I think it would be reasonable to have a “heredoc” like scheme, which does not allow leading indentation, and does work with all the same modifier characters above. I do not have a preference on a particular syntax, and haven’t given it any thought, but this would allow you to do things like:   let str = \<\ \ \t\ \t\t\\(author)\ \t\ \ EOF for example. You could then turn off escaping and other knobs using the modifier character (somehow, it would have to be incorporated into the syntax of course). I generally agree with your down thread remarks about how Swift doesn’t like to have multiple different solutions for the same problem. OTOH, you could look at “” syntax as being analogous to closure exprs, and heredoc syntax as being analogous to nested functions :-) -Chris > **···** > > > On Apr 23, 2016, at 2:08 PM, Brent Royal-Gordon via swift-evolution \ wrote: ---
**Author:** ![dabrahams](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/dabrahams/32/9815_2.png) [@dabrahams](https://forums.swift.org/u/dabrahams)\ **Post date:** [April 26, 2016, 9:54pm UTC](https://forums.swift.org/t/optional-dictionary-subscripts/719/17 "2016-04-26T21:54:00Z")
> As a long time user of Perl, for me the simplicity and lack of flexibility is the attraction > when it comes to “”” syntax ;) That’s a lot of documentation for just specifying a string. > > Perl makes life difficult for itself due to it’s rather simplistic $var interpolation syntax > which means you frequently want an un-interpolated string literal. The situation is > far better in Swift with the more distinct \(). > > Can you think of anything that couldn’t be readily expressed using > Python style “””? I've long held that the python string quoting styles “just work” and we should appropriate them rather than reinventing the wheel. In particular, the ability to write raw strings such as      r'something containing backslashes (\) and quotes (")' and      r"""something containing backslashes (\), quotes (") and      newlines!""" economically is extremely useful. When one needs to embed a fairly large block of text in source, the ability to use the triple-quoted forms \*without\* injecting noise on each line is fantastic. > **···** > > on Fri Apr 22 2016, John Holdsworth \ wrote: > > > John > > > > > On 22 Apr 2016, at 19:12, Patrick Gili \ wrote: > > > > > > This doesn't provide very much flexibility. I'd like to see something more like Perl6's quoting constructs: [GitHub - Raku/old-design-docs: Raku language design documents](https://doc.perl6.org/language/quoting%5C). > > > > > > -Patrick > > > > > > > On Apr 22, 2016, at 12:59 PM, John Holdsworth via swift-evolution \ wrote: > > > > > > > > I’ve raised a speculative PR against the Swift Lexer to support multi-line string literals as was > > > > suggested in the very first week Swift was open sourced and before that in various radars. > > > > > > > > [[Parse] Adjust Lexer to allow Multi-line string literals by johnno1962 · Pull Request #2275 · apple/swift · GitHub](https://github.com/apple/swift/pull/2275) > > > > > > > > The approach taken is as simple as possible defining multi-line strings as being > > > > delimited by “”” instead of “ and thereafter able to contain new line characters. > > > > > > > > There has been some discussion of this before on swift-evolution: > > > > > > > > [[swift-evolution] multi-line string literals](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001565.html) > > > > > > > > I’m trying to avoid more advanced features such as the handling of indenting which > > > > for me complicates something that if kept simple can be documented very easily. > > > > > > > > This change will require a evolution proposal so I’d like to take the pulse before I write it up. > > > > > > > > Thoughts? > > > > > > > > John > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > > swift-evolution mailing list > > > > swift-evolution@swift.org > > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > -- > Dave ---
**Author:** ![Brent\_Royal-Gordon](https://avatars.discourse-cdn.com/v4/letter/b/53a042/32.png) [@Brent\_Royal-Gordon](https://forums.swift.org/u/Brent_Royal-Gordon)\ **Post date:** [April 27, 2016, 1:24am UTC](https://forums.swift.org/t/optional-dictionary-subscripts/719/18 "2016-04-27T01:24:17Z")
> Just ignore me if that's been covered in the archives already (there is a lot there, I'm still catching up), but is there a reason we can't just allow newlines in the existing string constants and be done with it? Since they've been invalid so far, nobody has code that contains line breaks that could be broken. At worst the code formatter would have to be told not to indent such lines, but beyond that, why are newlines in strings not permitted? In short: Runaway strings. If you forget to include an ending ", the resulting error may be miles away from where you actually made a mistake. > **···** > > -- > Brent Royal-Gordon > Architechies ---
**Author:** ![Uli\_Kusterer](https://avatars.discourse-cdn.com/v4/letter/u/838e76/32.png) [@Uli\_Kusterer](https://forums.swift.org/u/Uli_Kusterer)\ **Post date:** [April 27, 2016, 1:36am UTC](https://forums.swift.org/t/optional-dictionary-subscripts/719/19 "2016-04-27T01:36:12Z")
Doesn't strike me as a problem needing a solution, though. Strings are syntax-colored differently than actual code. So if it's really runaway, you're likely to notice the wrong color. And the likelihood of the code actually still compiling after grabbing the next random quote to terminate its string is rather small, too. Cheers, -- Uli Kusterer "The Witnesses of TeachText are everywhere..." > **[Home](https://stacksmith.org/)** > > Stacksmith - A tool for making apps for non-programmers. > **···** > > On 27 Apr 2016, at 03:24, Brent Royal-Gordon \ wrote: > > > > Just ignore me if that's been covered in the archives already (there is a lot there, I'm still catching up), but is there a reason we can't just allow newlines in the existing string constants and be done with it? Since they've been invalid so far, nobody has code that contains line breaks that could be broken. At worst the code formatter would have to be told not to indent such lines, but beyond that, why are newlines in strings not permitted? > > > > In short: Runaway strings. If you forget to include an ending ", the resulting error may be miles away from where you actually made a mistake. ---
**Author:** ![Patrick\_Gili](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/patrick_gili/32/6033_2.png) [@Patrick\_Gili](https://forums.swift.org/u/Patrick_Gili)\ **Post date:** [April 23, 2016, 5:52pm UTC](https://forums.swift.org/t/optional-dictionary-subscripts/719/20 "2016-04-23T17:52:48Z")
This is oversimplifying the problem of escaping. Simply relaxing the grammar for the content of the string literal doesn't always work. For example, a regular expression that detects a might be written "\N\*\n". If escaping is enabled, then the compiler changes "\n" into line feed, which does not have the same meaning to the regular expression engine as "\n". -Patrick > **···** > > > On Apr 22, 2016, at 11:13 PM, John Holdsworth \ wrote: > > > > Regex support certainly needs to be kept in mind. I can propose something a little different > > on that front however that retains the existing simple literal syntax. Bear with me. > > > > What if invalid escape sequences did not result in an error but were passed through to the string? > > This is a very small change to the lexer. > > > > For example: > > > > > print( “\w+[\w\d]+” ) > > > > \w+[\w\d]+ > > > > It’s easy for a developer to know there are only seven valid escapes \0, \r, \n, \”, \’, \\ and \u{NNNN} > > so the error is not a particularly helpful one and these escapes do not overlap with regex syntax. > > > > In this way you get the best of both worlds, minimalist string syntax and not have to write “\\w+[\\w\\d]+” > > > > John > > > > > On 22 Apr 2016, at 20:54, Patrick Gili \ wrote: > > > > > > If we use a quoting structure similar to Perl6, then we future proof the grammar to accommodate regular expression literals (and multi-line regular expression literals) later. It also gives us the possibility for support for fine-grain control over escaping and interpolation. > > > > > > -Patrick > > > > > > > On Apr 22, 2016, at 2:48 PM, John Holdsworth \ wrote: > > > > > > > > As a long time user of Perl, for me the simplicity and lack of flexibility is the attraction > > > > when it comes to “”” syntax ;) That’s a lot of documentation for just specifying a string. > > > > > > > > Perl makes life difficult for itself due to it’s rather simplistic $var interpolation syntax > > > > which means you frequently want an un-interpolated string literal. The situation is > > > > far better in Swift with the more distinct \(). > > > > > > > > Can you think of anything that couldn’t be readily expressed using Python style “””? > > > > > > > > John > > > > > > > > > On 22 Apr 2016, at 19:12, Patrick Gili \ wrote: > > > > > > > > > > This doesn't provide very much flexibility. I'd like to see something more like Perl6's quoting constructs: [GitHub - Raku/old-design-docs: Raku language design documents](https://doc.perl6.org/language/quoting%5C). > > > > > > > > > > -Patrick > > > > > > > > > > > On Apr 22, 2016, at 12:59 PM, John Holdsworth via swift-evolution \ wrote: > > > > > > > > > > > > I’ve raised a speculative PR against the Swift Lexer to support multi-line string literals as was > > > > > > suggested in the very first week Swift was open sourced and before that in various radars. > > > > > > > > > > > > [[Parse] Adjust Lexer to allow Multi-line string literals by johnno1962 · Pull Request #2275 · apple/swift · GitHub](https://github.com/apple/swift/pull/2275) > > > > > > > > > > > > The approach taken is as simple as possible defining multi-line strings as being > > > > > > delimited by “”” instead of “ and thereafter able to contain new line characters. > > > > > > > > > > > > There has been some discussion of this before on swift-evolution: > > > > > > > > > > > > [[swift-evolution] multi-line string literals](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001565.html) > > > > > > > > > > > > I’m trying to avoid more advanced features such as the handling of indenting which > > > > > > for me complicates something that if kept simple can be documented very easily. > > > > > > > > > > > > This change will require a evolution proposal so I’d like to take the pulse before I write it up. > > > > > > > > > > > > Thoughts? > > > > > > > > > > > > John > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > > > > swift-evolution mailing list > > > > > > swift-evolution@swift.org > > > > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) [Next page](https://forums.swift.org/t/optional-dictionary-subscripts/719.md?page=2)