<div dir="ltr">On Thu, Nov 23, 2017 at 2:47 PM, Tony Allevato <span dir="ltr"><<a href="mailto:tony.allevato@gmail.com" target="_blank">tony.allevato@gmail.com</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 dir="ltr"><br><br><div class="gmail_quote"><span class=""><div dir="ltr">On Thu, Nov 23, 2017 at 12:21 PM Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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><div dir="ltr"><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="m_1564448746614413503m_-5363165877139667316h5"><div><div><blockquote type="cite"><div></div></blockquote></div></div></div></div></div></div></div></div></blockquote></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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></div></div></div></blockquote><div><br></div></span><div>Unless I'm misunderstanding you here, I don't think that's true: writing something like `let c: Character = "ab"` is definitely a compile-time error: <a href="https://gist.github.com/allevato/ae267e2aaaa7939d6233d66a87b48fc0" target="_blank">https://gist.github.<wbr>com/allevato/<wbr>ae267e2aaaa7939d6233d66a87b48f<wbr>c0</a></div></div></div></blockquote><div><br></div><div>Hmm, yes, it still attempts to make a best effort, it seems. I had thought that this compile-time check was removed altogether, as it cannot be done in the general case.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div></div><div>To the original point though, I don't think Swift needs to use single quotes for single characters (or single scalars). Type inference already infers Characters from single-character String literals in contexts where a Character is expected, and the only time you need to be explicit is if you're trying to resolve an overload or initialize a variable by itself. Using single quotes to avoid writing "as Character" would feel like a waste.</div><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><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"><div><div><div><div class="m_1564448746614413503m_-5363165877139667316h5"><div><div><blockquote type="cite"><div></div></blockquote></div></div></div></div></div></div></div></div></blockquote></div></div></div></blockquote></span></div></div></blockquote><div>Agree. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><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"><div><div><div><div class="m_1564448746614413503m_-5363165877139667316h5"><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_1564448746614413503m_-5363165877139667316m_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" target="_blank">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></div></div>
______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">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>
</blockquote></span></div></div>
</blockquote></div><br></div></div>