aren’t all literals evaluated at compile time? On Thu, Nov 23, 2017 at 6:07 PM, Tony Allevato <tony.allev...@gmail.com> wrote:
> 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. > > If UInt8 conformed to ExpressibleByUnicodeScalarLiteral, 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. > > 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). > > 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. > > > On Thu, Nov 23, 2017 at 2:43 PM Kelvin Ma <kelvin1...@gmail.com> wrote: > >> On Thu, Nov 23, 2017 at 3:47 PM, Tony Allevato via swift-evolution < >> swift-evolution@swift.org> wrote: >> >>> >>> >>> On Thu, Nov 23, 2017 at 12:21 PM Xiaodi Wu via swift-evolution < >>> swift-evolution@swift.org> wrote: >>> >>>> On Thu, Nov 23, 2017 at 2:14 PM, John Holdsworth via swift-evolution < >>>> swift-evolution@swift.org> wrote: >>>> >>>>> I’m beginning to wish I hadn’t tied this proposal so strongly to >>>>> regular expressions! >>>>> It is indeed the wrong motivation. Even as a ten year veteran of Perl >>>>> development >>>>> I’m not sure we want to bake it into the language quite so tightly >>>>> (isn’t a part of >>>>> Foundation?) What would /regex/ represent - an instance of >>>>> NSRegularExpression? >>>>> Would the flags be pattern options or matching options? This is a >>>>> whole other debate. >>>>> >>>>> For me the focus of raw strings was a sort of super-literal literal >>>>> which has many >>>>> applications. The r”literal” syntax has a precedent in Python and >>>>> there seemed >>>>> to be a syntactic gap that could be occupied but perhaps there are >>>>> other alternatives >>>>> we could discuss. It would be a shame to see ‘quoted strings’ be used >>>>> for this however. >>>>> I still live in hope one day it will be used for single character >>>>> UNICODE values. >>>>> >>>>> 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. >>>> >>> >>> 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: https://gist.github.com/allevato/ae267e2aaaa7939d6233d66a87b48fc0 >>> >>> 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. >>> >> >> 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. >> >>
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution