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

[Félix Cloutier]

> What is your evaluation of the proposal?

-1, approximately.

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

I don't necessarily think that the concept is a bad idea, but I think that the interaction of Swift features facilitates poor coding decisions. For example, the proposal interpolates an `author` variable straight into an XML document, and suggests doing the same to JSON strings. To me, this shows that an important use case of the feature is to format payloads in a way that is known to cause vulnerabilities.

Of course, you can already shoot yourself in the foot that way with short strings, but at least, it looks ugly. Come up with a solution that looks better and people will stop using the ugly one. The long string version looks good despite being dangerous, and I think that it would compete with safe efforts.

You can also say that it's the developer's responsibility to make sure that you don't misuse it. I disagree. I think that SQL injections and the like have caused enough damage that it's time to change attitudes.

To be clear, I wouldn't be opposed to large strings that can't interpolate (but I don't think that they would be extremely useful).

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

I think that it's a secondary concern. There are better, type-safe, and not much more cumbersome ways to create XML and JSON documents that don't open careless developers to injection vulnerabilities, which are much more Swift-like ways to solve that problem. I would rather have the community work on that kind of solution than to make strings look like the right tool.

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


If you remove interpolation support from long strings, they aren't particularly compelling anymore. I use long strings in Python for documentation and not much else; but Swift uses comments for documentation. There are just not that many places where you need long strings outside of quick-and-dirty payload formatting, and printing your --help message (assuming that the community doesn't come up with a great option parsing library, if that doesn't already exist).

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

I've done enough reading to know that my opinion is unpopular. :)

> Le 6 avr. 2017 à 12:35, Joe Groff via swift-evolution <swift-evolution at swift.org> a écrit :
> 
> 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?
> 	• 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 <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/122b9cba/attachment.html>