[swift-evolution] [Review] SE-0168: Multi-Line String Literals

John Holdsworth mac at johnholdsworth.com
Wed Apr 12 16:41:20 CDT 2017


There isn’t much in it TBH and I could live with either. Option 1 seems to have been a regression.

Option 3 is the pure route in one sense but for me Option 2 the more practical which I
was hoping to demonstrate with the example strings. I’d also ague lines should be
complete (have line endings unless escaped) by default in a multiline string.

> On 12 Apr 2017, at 22:31, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
> 
> John, why do you think that option 2 is superior to option 3?
> 
> 
> On Wed, Apr 12, 2017 at 16:14 John Holdsworth via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> I think we’re agreeing. Looks like I need to clarify my last post a little. When I included the following strings:
> 
>         let longstring = """\
>             Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod \
>             tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, \
>             quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.\
>             """
> 
>         print( """\
>             Usage: myapp <options>
>             
>             Run myapp to do mything
>             
>             Options:
>             -myoption - an option
>             """ )
> 
> These were expressed in term of the proposal after last nights changes.
> 
> By advocating option 2) I’m accepting we should revert back to the following:
> 
>         let longstring = """
>             Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod \
>             tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, \
>             quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.\
>             """
> 
>         print( """
>             Usage: myapp <options>
>             
>             Run myapp to do mything
>             
>             Options:
>             -myoption - an option
>             ""” )
> 
>> 1) Proposal as it stands  - no magic removal of leading/training blank lines.
>> 2) Removal of a leading blank line when indent stripping is being applied.
>> 3) Removal of leading blank line and trailing newline when indent stripping is being applied.
> 
> 
> Also, note: the toolchain does not seem to work at all with playgrounds. I’ve been using small test apps.
> 
>> On 12 Apr 2017, at 21:06, Adrian Zubarev via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> Exactly, I feel like we found a Swifty version of a multi-line string literal. :)
>> 
>> 
>> 
>> 
>> -- 
>> Adrian Zubarev
>> Sent with Airmail
>> 
>> Am 12. April 2017 um 21:58:37, Vladimir.S via swift-evolution (swift-evolution at swift.org <mailto:swift-evolution at swift.org>) schrieb:
>> 
>>> this:
>>> """
>>> one
>>> two
>>> """
>>> should be just the same as "one\ntwo\n"
>>> 
>>> If one wants some advanced tuning of line ends, he/she can use a backslash, for example
>>> """
>>> one
>>> two\
>>> """
>>> should produce "one\ntwo"
>> 
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>

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


More information about the swift-evolution mailing list