<div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif">OK, I understand your problem better with that example. Perhaps a solution would be to have """ process escapes while ''' starts a "raw" string. This is very much in line with ruby's style of strings where processing isn't done within single quoted strings:</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div class="gmail_default"><div class="gmail_default"><font face="monospace, monospace">irb(main):001:0> foo = 2</font></div></div><div class="gmail_default"><div class="gmail_default"><font face="monospace, monospace">=> 2</font></div></div><div class="gmail_default"><div class="gmail_default"><font face="monospace, monospace">irb(main):002:0> "#{foo}"</font></div></div><div class="gmail_default"><div class="gmail_default"><font face="monospace, monospace">=> "2"</font></div></div><div class="gmail_default"><div class="gmail_default"><font face="monospace, monospace">irb(main):003:0> '#{foo}'</font></div></div><div class="gmail_default"><div class="gmail_default"><font face="monospace, monospace">=> "\#{foo}"</font></div></div></blockquote><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">(Ignore that \# at the end there; that's only because the interactive console returns a double quoted string. I assure you, the contents are unescaped.)</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">If we go with this syntax for escaped and unescaped strings, then for consistency's sake it would make sense to have single-line single-quoted strings that don't escape and are "raw" strings like in ruby.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">CCing Chris Lattner here specifically because, in swift today, using single quotes gives you a warning to just use double quotes, so he might have a strong opinion on this one. The latest commit to Lexer.cpp was actually to add better handling of single quoted strings (and I think more warnings if I remember?).<br></div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">- Travis Tilley</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 11, 2015 at 6:01 AM, Drew Crawford <span dir="ltr"><<a href="mailto:drew@sealedabstract.com" target="_blank">drew@sealedabstract.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><span class=""><div><blockquote type="cite"><div>On Dec 11, 2015, at 1:27 AM, Travis Tilley <<a href="mailto:ttilley@gmail.com" target="_blank">ttilley@gmail.com</a>> wrote:</div><br><div><span 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></span><div>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><span class=""><div><br></div><div><blockquote type="cite"><span style="font-family:verdana,sans-serif">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></div></span><div>I don’t believe this is true in full generality. An illustration from the type system:</div><div><br></div><div></div><blockquote type="cite"><div>let a: Int16 = 0</div><div>let b: Int32 = 0</div><div>if a & b { }</div></blockquote><br><div>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><br></div><div>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><span class=""><div><br></div><div></div><blockquote type="cite">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><br></div></span><div>So for example, consider an object.json:</div><div><br></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div> {</div><div> "foo": "bar",</div><div> "baz": "bap\nbap"</div><div>}</div></blockquote><div><br></div><div>Now I paste that into my Swift sourcode:</div><div><br></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>let sampleJSON = """</div><div>{</div><div> "foo": "bar",</div><div> "baz": "bap\nbap"</div><div>}</div><div>"""</div></blockquote><div><br></div><div>Now if Swift escapes this, and thinks I wanted:</div><div><br><br></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>{</div><div> "foo": "bar",</div><div> "baz": "bap</div><div>bap"</div><div>}</div></blockquote><div><br></div><div><br></div><div>This is no longer valid JSON, and I get a mystery parse error. </div><div><br></div><div>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" target="_blank">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" target="_blank">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><br></div><div>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><br></div><div>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><br></div></div></div></blockquote></div><div><br></div>
</div></div>