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

Ben Cohen ben_cohen at apple.com
Fri Apr 7 12:14:31 CDT 2017

> On Apr 6, 2017, at 12:35 PM, Joe Groff via swift-evolution <swift-evolution at swift.org> wrote:
> 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 <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 <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 <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?

A firm +1. This is an important feature for a number of different use cases. I should note that improving ergonomics for scripting, testing, and knocking together quick sample code are goals in themselves, even if you feel it would be bad to include big gobs of string literal in “real” code – you can simply ignore this feature if you feel it’s inappropriate in that use case. Unlike, say, adding keywords, it does not expand the overall surface area of the language in a way that will harm existing use or be confusing to people encountering it for the first time.

I understand the concerns re clarifying the exact behavior. I think these are more assumptions that need to be explicitly documented than flaws that would block accepting the proposal once those clarifications are added and circulated.

> 	• Is the problem being addressed significant enough to warrant a change to Swift?

Yes. I find myself wanting this on a regular basis.

> 	• Does this proposal fit well with the feel and direction of Swift?

Yes, and also fits well with the current focus on String improvements in Swift 4.

> 	• If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

Of the various different options from different languages, I feel this is the best. The syntax is lightweight, which is important. The ability to cut+paste* text directly is a big win over continuation quotes, which I find fiddly to maintain and ugly to read. I like the ability to indent, especially for scripting. Triple quotes are simpler than heredoc, including for new users.

*most text – I don’t think code including specific cases like including triple-quotes or other escaped values is a showstopper, so long as these exceptions are explicitly called out.

> 	• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

A fair amount.

> More information about the Swift evolution process is available at:
> https://github.com/apple/swift-evolution/blob/master/process.md <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/20170407/a01bafe8/attachment.html>

More information about the swift-evolution mailing list