<div dir="ltr">On Thu, Nov 23, 2017 at 2:14 PM, John Holdsworth via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div dir="auto" style="word-wrap:break-word">I’m beginning to wish I hadn’t tied this proposal so strongly to regular expressions!<div>It is indeed the wrong motivation. Even as a ten year veteran of Perl development</div><div>I’m not sure we want to bake it into the language quite so tightly (isn’t a part of</div><div>Foundation?) What would /regex/ represent - an instance of NSRegularExpression?</div><div>Would the flags be pattern options or matching options? This is a whole other debate.<div><br></div><div>For me the focus of raw strings was a sort of super-literal literal which has many</div><div>applications. The r”literal” syntax has a precedent in Python and there seemed</div><div>to be a syntactic gap that could be occupied but perhaps there are other alternatives </div><div>we could discuss. It would be a shame to see ‘quoted strings’ be used for this however.</div><div>I still live in hope one day it will be used for single character UNICODE values.</div><div><div><div class="h5"><div><div><blockquote type="cite"><div></div></blockquote></div></div></div></div></div></div></div></div></blockquote><div>Since what passes for a single character changes by Unicode revision--such as whenever they get around to enumerating the permitted modifying attributes of the poop emoji--it is quite impossible (and Swift's `Character` doesn't attempt to) to enforce single-characterness at compile time. We should put any such notions to rest up front.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div dir="auto" style="word-wrap:break-word"><div><div><div><div class="h5"><div><div><blockquote type="cite"><div>On 23 Nov 2017, at 19:10, Brent Royal-Gordon <<a href="mailto:brent@architechies.com" target="_blank">brent@architechies.com</a>> wrote:</div><br class="m_7128571747680734925Apple-interchange-newline"><div><div dir="auto"><div><font><span style="background-color:rgba(255,255,255,0)">On Nov 23, 2017, at 11:15 AM, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br><br></span></font></div><blockquote type="cite"><font><span style="background-color:rgba(255,255,255,0)">Until we figure out that path forward for regex’s, I think they aren’t the right motivation for this proposal.</span></font></blockquote><div><br></div><div>1. Even in our shining pattern matching future—a future which I, for one, am eager to hasten—we will still need to interoperate with NSRegularExpression and other Perl 5-compatible regex engines.</div><div><br></div><div>2. Code generation.</div><div><br></div><div>3. Windows-style paths. </div><div><br></div><div>4. Doesn’t LaTeX use backslashes?</div><div><br></div><div>5. Etc. </div><div><br></div><div>I think the Motivation section undersells this proposal. Regexes are a strong short-run use case, but in the long run, we’ll need this for other things. In both cases, though, raw literals will be a useful addition to the language, improving the clarity of Swift code much like multiline literals already have. </div><br><div><div>-- </div><div>Brent Royal-Gordon</div>Sent from my iPhone</div><div><br></div></div></div></blockquote></div><br></div></div></div></div></div></div></div><br>______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
<br></blockquote></div><br></div></div>