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

Félix Cloutier felixcca at yahoo.ca
Sun Apr 9 22:46:43 CDT 2017


To be clear, I don't think that it's a particularly powerful footgun. It's just perpetuating the unfortunate status quo on injection vulnerabilities. C# was able to eliminate the whole class of SQL injections by introducing a convenient and powerful syntax for queries that is not string-based. I think that Swift should be moving in that direction, especially since no one has made any other case for long strings so far.

For JSON, it's easy to imagine something like `let json: JsonObject = ["a": "b", "c": ["d": 3]]` (to take Kevin's example) being a safer alternative than long strings, with or without interpolation. Reflection could also be used to serialize objects.

For XML, I know that you have this XMLString idea, but I think that it would be very complex to implement in practice. XML has several different contexts in which escaping has to be different. For instance, you shouldn't escape the same things in an attribute value as in a comment, or in an XML text node, or in a CDATA node, and that means that you have to be aware of what you're looking for at the point where interpolation happens. It's also possible to come up with uncheckable/incorrect cases (like `<foo \(bar)>`), meaning that it either has to accept anything in some cases or be failable (and besides, "just remove :XMLString and it works!"). Until Swift gets compile-time evaluation of expression, this cannot be a compile-time error.

> Le 9 avr. 2017 à 19:44, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org> a écrit :
> 
>> On Apr 9, 2017, at 9:29 AM, John Holdsworth via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> Perhaps we can find common ground on 1) and 2) and even 3) with a view to resubmitting if there is time. Seems mostly like we just need to discuss the delimiter further and decide whether the indent trimming is a bug or a feature to keep moving and not let another year slip by.
> 
> Honestly, I think this is a little premature. If I had to summarize this thread, I think what I'm seeing is:
> 
> 	1. We wish the proposal were more specific on a few points, like the de-indenting algorithm.
> 
> 	2. We have lots of different pet syntaxes and preferences.
> 
> 	3. But most of us are still in favor of accepting the proposal.
> 
> To back up that last point, I ran through the thread and tried to quickly figure out what everyone was thinking. These people seem to be opposed to the proposal: 
> 
> 	1. Haravikk doesn't like the de-indenting and seems iffy on multiline strings in general.
> 	2. David Waite wants a suite of different, orthogonal string literal features to get enough flexibility.
> 	3. Félix Cloutier is worried that supporting interpolation makes this feature a powerful footgun.
> 	4. Adrian Zubarev wants to extend single-quoted string literals instead of developing a second syntax.
> 
> These people want the proposal to be more specific, but appear to be in favor as long as the missing details don't reveal problems:
> 
> 	1. Greg Parker (maybe?)
> 	2. Xiaodi Wu
> 	3. Gwendel Roué
> 
> And these people all seem basically positive, though sometimes with reservations or bikeshedding suggestions:
> 
> 	1. Me
> 	2. Tony Allevato
> 	3. David Hart
> 	4. Daniel Duan
> 	5. Ricardo Parada
> 	6. Kevin Nattinger
> 	7. Víctor Pimentel Rodríguez
> 	8. Jarod Long (I think)
> 	9. Ben Cohen
> 	10. Thorsten Seitz
> 	11. Howard Lovatt
> 	12. T.J. Usiyan
> 
> Evolution reviews are not referenda, but I think it's fair to say that the sentiment is mostly positive.
> 
> (And if the core team does say they like the approach but want clarifications, I'd be happy to pitch in and earn the co-author credit!)
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> _______________________________________________
> 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/20170409/9697db9a/attachment-0001.html>


More information about the swift-evolution mailing list