> 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@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@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

Reply via email to