[swift-evolution] [Review] SE-0168: Multi-Line String Literals
Adrian Zubarev
adrian.zubarev at devandartist.com
Sat Apr 8 05:59:10 CDT 2017
What is your evaluation of the proposal?
–1 for the proposed solution, but in general I’d myself would want to see multi-line strings in Swift. The current proposal does not cover precision, which could also be desired by developers.
My _personal_ view on how I wish multi-line strings do behave is actually similar to the magical string concatenation which is an optimization during compile time (not included in Xcode 8.3). Many people disagree with this point of view in favor of implicit new lines and non escaped " character, which is fine by me only if we can extend the standard string literal to support multilines too. Such extension will be stricter and have special precision rules.
// Simplicity which supports indent but at a cost of no
// leading or trailing space characters
let string1 = "my
multiline
string"
print(string1) // prints "mymultilinestring"
let string2 = "my \
multiline \
string"
// Trailing precision
print(string2) // prints "my multiline string"
let string3 = "my
" multiline
" string"
// Leading precision
print(string3) // prints "my multiline string"
let string4 = "my \
" multiline \
" string"
// Leading and trailing precision
print(string4) // prints "my multiline string" (Note: 2x two whitespaces)
let string5 = "my\
"multiline\
"string"
// Leading and trailing precision
// Provide a fix-it to remove some `\` and `"` characters
// because it equals `string1`
print(string5) // prints "mymultilinestring"
let string6 = "my \
"multiline \
"string"
// Leading and trailing precision
// Provide a fix-it to remove some `"` characters
// because it equals `string2`
print(string6) // prints "my multiline string"
let string7 = "my\
" multiline\
" string"
// Leading and trailing precision
// Provide a fix-it to remove some `\` characters
// because it equals `string3`
print(string7) // prints "my multiline string"
Additionally you can support a similar version of multilines strings with """ notation for those of use who are lazy to type \n and \" and want implicit new lines. However this raises the question, if the addition of """ is warrant it’s existence only for laziness and copy pasting?
The above example should also support string interpolation.
Is the problem being addressed significant enough to warrant a change to Swift?
Not enough from my point of view.
Does this proposal fit well with the feel and direction of Swift?
The addition of multi-lined strings does fit, however I don’t think the proposed solution satisfies everyone. Personally I’d probably never use a multi-lined string as proposed, just because it adds implicit new lines to my very long string, which I maybe only want to break up into a few lines for better readability without the boilerplate of the not so obvious optimization magic provided by the complier though the concatenation operator +.
I think the correct name is *multi line string literal*, which is different from _multi line string_. The former should not have any implicit behavior except if there are two different versions like "__" and """___""".
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
Javascript has this nice ability to break up strings into multilines with trailing precision, which I used in the example above.
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
Read the whole proposal and took part in latest discussion thread.
--
Adrian Zubarev
Sent with Airmail
Am 6. April 2017 um 21:35:50, Joe Groff via swift-evolution (swift-evolution at swift.org) schrieb:
Hello Swift community,
The review of SE-0168 "Multi-Line String Literals" begins now and runs through April 12, 2017. The proposal is available here:
https://github.com/apple/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md
Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at:
https://lists.swift.org/mailman/listinfo/swift-evolution
or, if you would like to keep your feedback private, directly to the review manager. When replying, please try to keep the proposal link at the top of the message:
Proposal link:
https://github.com/apple/swift-evolution/blob/master/proposals/0167-swift-encoders.md
Reply text
Other replies
What goes into a review?
The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
• What is your evaluation of the proposal?
• Is the problem being addressed significant enough to warrant a change to Swift?
• Does this proposal fit well with the feel and direction of Swift?
• If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
More information about the Swift evolution process is available at:
https://github.com/apple/swift-evolution/blob/master/process.md
Thank you,
-Joe
Review Manager
_______________________________________________
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/20170408/6cb6ab25/attachment.html>
More information about the swift-evolution
mailing list