<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">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.<div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.<br class=""><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">Le 9 avr. 2017 à 19:44, Brent Royal-Gordon via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class="">On Apr 9, 2017, at 9:29 AM, John Holdsworth via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;">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.</div></div></blockquote><br class=""></div><div class="">Honestly, I think this is a little premature. If I had to summarize this thread, I think what I'm seeing is:</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>1. We wish the proposal were more specific on a few points, like the de-indenting algorithm.</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>2. We have lots of different pet syntaxes and preferences.</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>3. But most of us are still in favor of accepting the proposal.</div><div class=""><br class=""></div><div class="">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: </div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>1. Haravikk doesn't like the de-indenting and seems iffy on multiline strings in general.</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>2. David Waite wants a suite of different, orthogonal string literal features to get enough flexibility.</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>3. Félix Cloutier is worried that supporting interpolation makes this feature a powerful footgun.</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>4. Adrian Zubarev wants to extend single-quoted string literals instead of developing a second syntax.</div><div class=""><br class=""></div><div class=""><div class="">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:</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>1. Greg Parker (maybe?)</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>2. Xiaodi Wu</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>3. Gwendel Roué</div></div><div class=""><br class=""></div><div class="">And these people all seem basically positive, though sometimes with reservations or bikeshedding suggestions:</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>1. Me</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>2. Tony Allevato</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>3. David Hart</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>4. Daniel Duan</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>5. Ricardo Parada</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>6. Kevin Nattinger</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>7. Víctor Pimentel Rodríguez</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>8. Jarod Long (I think)</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>9. Ben Cohen</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>10. Thorsten Seitz</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>11. Howard Lovatt</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>12. T.J. Usiyan</div><div class=""><br class=""></div><div class="">Evolution reviews are not referenda, but I think it's fair to say that the sentiment is mostly positive.</div><div class=""><br class=""></div><div class="">(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!)</div><br class=""><div class="">
<span class="Apple-style-span" style="border-collapse: separate; font-variant-ligatures: normal; font-variant-east-asian: normal; font-variant-position: normal; line-height: normal; border-spacing: 0px;"><div class=""><div style="font-size: 12px; " class="">-- </div><div style="font-size: 12px; " class="">Brent Royal-Gordon</div><div style="font-size: 12px; " class="">Architechies</div></div></span>
</div>
<br class=""></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></div></body></html>