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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
