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
