[swift-dev] Nested multi-line string literals

[Jean-Pierre Simard]

Looks like both those cases are supported based on similar tests here:
https://github.com/apple/swift/blob/master/test/Parse/multiline_string.swift

Should be available in snapshots
`swift-4.0-DEVELOPMENT-SNAPSHOT-2017-05-09-a` onwards.

On Wed, 31 May 2017 at 13:59 Nathan Hawes via swift-dev <swift-dev at swift.org>
wrote:

> Hey all,
>
> I’ve been playing with multi-line string literals recently and was
> wondering, are the below cases supported intentionally or did they just
> fall out of the implementation?
>
> 1) Nested multi-line strings:
>
> let x = """
> outer multi-line
> \(
>   """
>     inner multiline
>   """
> )
> outer multi-line
> """
> print(x)
>
>
> 2) Multi-line strings nested in "single-line" strings:
>
> let x = "outer string \( """
>     inner multiline
>   """) outer string"
> print(x)
>
> I’ve been looking at still syntax highlighting strings in the invalid
> states they pass through while writing or editing them, and trying to keep
> any changes to the file’s highlighted ranges as localized as possible. At
> the moment when you open an interpolation in an otherwise terminated
> multi-line string literal you get one giant  unknown token – an
> unterminated string – from the opening triple quotes, past the ‘closing’
> triple quotes (that we treat as nested opening quotes), to the end of the
> file.
>
> It’d be great to be able to bound the unknown token to what were more
> likely intended to be closing quotes, so we still produce tokens for (and
> syntax highlight) the rest of the file. Of course with nesting you can’t be
> sure they’re closing quotes though, so I wanted to check if the nesting
> support was intentional.
>
> Thanks!
> Nathan
> _______________________________________________
> swift-dev mailing list
> swift-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20170531/4dabb71f/attachment.html>