<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=""><br class=""><div class=""><div><blockquote type="cite" class=""><div class="">On Dec 11, 2015, at 1:27 AM, Travis Tilley <<a href="mailto:ttilley@gmail.com" class="">ttilley@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><span class="" style="font-family: verdana, sans-serif; float: none; display: inline !important;">I think there are many more use cases than you suggest in #1. </span></div></blockquote></div><br class=""><div class="">I didn’t intend this to be read narrowly, sorry! I simply mean that I don’t have a good handle on why people want this feature, I think it might be good to investigate that question to help inform the design rather than assume everybody else is thinking of the same use case each of us individually may have in mind. Your Docopt example was very helpful in this regard, I feel like I better understand your problems. I agree that escaped strings are the ‘sane’ default to serve a use case like Docopt.</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><span style="font-family: verdana, sans-serif;" class="">As for your question #2... I believe that the sane option should always be the easiest, and the less sane option should be possible, but with "syntactic vinegar" to make it less pleasant to use.</span></blockquote><br class=""></div><div class="">I don’t believe this is true in full generality. An illustration from the type system:</div><div class=""><br class=""></div><div class=""></div><blockquote type="cite" class=""><div class="">let a: Int16 = 0</div><div class="">let b: Int32 = 0</div><div class="">if a & b { }</div></blockquote><br class=""><div class="">There are two ways to resolve this: the “sane” option is to promote `a` to Int32—the insane option is to demote `b` to Int16. Swift rejects both, gives you a compile error, and tells you to sort it out yourself.</div><div class=""><br class=""></div><div class="">Having “default” and “optout” behavior is correct sometimes, right? As is sending it back to the programmer for clarification. What I’m asking is how we distinguish between those two approaches that are both correct for some problems. Do you know any design principle that distinguishes these examples? There must be some reason we force a programmer to rewrite their implicit upcast but not their implicit escaped string.</div><div class=""><br class=""></div><div class=""></div><blockquote type="cite" class="">Please give me more info on what would make your specific use case less unpleasant. JSON/JavaScript escape sequences tend to correspond pretty well with swift (with notable exceptions).</blockquote><div class=""><br class=""></div><div class="">So for example, consider an object.json:</div><div class=""><br class=""></div><blockquote style="margin: 0px 0px 0px 40px; border: none; padding: 0px;" class=""><div class=""> {</div><div class=""> "foo": "bar",</div><div class=""> "baz": "bap\nbap"</div><div class="">}</div></blockquote><div class=""><br class=""></div><div class="">Now I paste that into my Swift sourcode:</div><div class=""><br class=""></div><blockquote style="margin: 0px 0px 0px 40px; border: none; padding: 0px;" class=""><div class="">let sampleJSON = """</div><div class="">{</div><div class=""> "foo": "bar",</div><div class=""> "baz": "bap\nbap"</div><div class="">}</div><div class="">"""</div></blockquote><div class=""><br class=""></div><div class="">Now if Swift escapes this, and thinks I wanted:</div><div class=""><br class=""><br class=""></div><blockquote style="margin: 0px 0px 0px 40px; border: none; padding: 0px;" class=""><div class="">{</div><div class=""> "foo": "bar",</div><div class=""> "baz": "bap</div><div class="">bap"</div><div class="">}</div></blockquote><div class=""><br class=""></div><div class=""><br class=""></div><div class="">This is no longer valid JSON, and I get a mystery parse error. </div><div class=""><br class=""></div><div class="">In the spirit of clattner’s “what do other languages do?”, I think it is instructive to look at what Pythonistas do with their Python multi-line syntax. Almost universally, they use (the default) <a href="http://stackoverflow.com/a/1872081" class="">escaped strings</a> to store JSON. Even people who should know better, <a href="https://github.com/simplejson/simplejson/blob/v2.3.3/simplejson/tests/test_pass3.py#L8" class="">because they are writing a JSON parser</a>, reach for escaped strings first. Escaped strings work until they don’t (e.g. in the example), and then they fail *badly*.</div><div class=""><br class=""></div><div class="">Think about the plight of a noob Swift 3 programmer who has Python syntax. StackOverflow questions will teach them to use escaped strings in this case. Then they paste their JSON into a linter and it comes back valid. Even if they go read a JSON parser they will learn to use escaped strings! I wonder if an entire class of bugs can be avoided by being more careful with the syntax in some way.</div><div class=""><br class=""></div><div class="">While I am motivating the example in terms of JSON specifically, it is much broader than one format—XML, YAML, Xcode build logs, CSV—are all cases where escaping might be a surprise, particularly in playgrounds.</div><div class=""><br class=""></div></div></body></html>