<div dir="ltr"><div>aren’t all literals evaluated at compile time?<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 23, 2017 at 6:07 PM, Tony Allevato <span dir="ltr"><<a href="mailto:tony.allevato@gmail.com" target="_blank">tony.allevato@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">This could be solved by extending the existing string literal handling and letting type inference do the rest. The real problem here is that `UInt8(ascii: X)` is annoying to write when you're dealing with a large amount of low-level data.<div><br></div><div>If UInt8 conformed to ExpressibleByUnicodeScalarLite<wbr>ral, you could get most of the way there—you'd just have to have it fail at runtime for anything outside 0...127. But then you could write `let c: UInt8 = "x"` and it would just work.</div><div><br></div><div>Failing at runtime is undesirable though, so you could take it further and add an ExpressibleByASCIILiteral protocol which would be known to the compiler, and it would emit an error at compile time if the literal wasn't a single ASCII character (like it does today for Character).</div><div><br></div><div>One of the things I think is really elegant about Swift is that string literals are untyped by themselves and take on an appropriate type based on the context they're used in. Handling different kinds of strings should leverage and extend that mechanism, not add new syntax.</div><div><br></div></div><div class="HOEnZb"><div class="h5"><br><div class="gmail_quote"><div dir="ltr">On Thu, Nov 23, 2017 at 2:43 PM Kelvin Ma <<a href="mailto:kelvin13ma@gmail.com" target="_blank">kelvin13ma@gmail.com</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"><div class="gmail_extra"><div class="gmail_quote">On Thu, Nov 23, 2017 at 3:47 PM, Tony Allevato via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></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><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_8646490931728862337m_8874035841581962641m_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'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><br></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></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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>
</blockquote></div>
</div></div></blockquote></div><br></div>