<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 23, 2017 at 3:47 PM, Tony Allevato via swift-evolution <span dir="ltr">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</span> wrote:<br><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 &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; 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">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</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_4157654344010000671m_-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&#39;s `Character` doesn&#39;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&#39;m misunderstanding you here, I don&#39;t think that&#39;s true: writing something like `let c: Character = &quot;ab&quot;` 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><br></div><div>To the original point though, I don&#39;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&#39;re trying to resolve an overload or initialize a variable by itself. Using single quotes to avoid writing &quot;as Character&quot; would feel like a waste.</div></div></div></blockquote><div><br></div><div>i still think single quotes should be used as an alternate literal for UInt8, like char. there’s a lot of cases where you’re working with low-level 8-bit ASCII data and both String and Character and Unicode.Scalar are inappropriate, and typing out hex literals makes code *less* readable.<br></div></div><br></div></div>