Here are some of my observations and perhaps a new avenue in the solution space.
Single quoted literals should clearly default to Character, which is the constituent element of a string at the level of human interpretation, and is the most common character-like type. This is a particularly beginner visible part of Swift.
It would be great to have improved egonomics for working with low level text processing, especially in ascii.
Conversion from Character literals to Numbers should be explicit and mention the encoding used. If this were not to be the case it would deviating substantially from the rest of the Swift language.
It seems that a branch of this discussion is exploring using single quoted literals to represent a Unicode.Scalar so that it becomes easier to have a trapping
ascii property that lets us write
let a: UInt8 = 'a'.ascii bypassing weird unicode normalisation edge cases such as
'\r\n' becoming a single character. Using trapping for this use case doesn't seem ideal because of the fact that it would be so easily triggered, and by making single quoted literals default to Unicode.Scalar this would exist in a prominent part of Swift.
Character already has an
let a = c.asciiValue //Optional(Int) property which is the correct form to use on an arbitrary character parameter. A trapping variant would only be useful when bound to a literal ie.
arbitrary.ascii //not useful
It seems to me that Swift is missing a langauge feature that would let us have the best overall outcome. That feature being Literal Bound Functions these would allow us to write the following, which is making use of a hypothetical literal bound
ascii property on character-literal.
let a = 'A' //inferred to be of type Character
let b = 'B'.ascii //b == 66
let c = getArbitraryCharacter()
let c1 = c.ascii //type Character has no such function
guard let c2 = c.asciiValue //this is the way to do it
Literal bound functions would be compiler evaluated and would operate on the literal before unicode normalisation so all of the drawbacks of using Character vs. Unicode.Scalar could be caught. A literal bound function could show up in code completion on a literal alongside those functions belonging to the default type.
You could also have a similar literal bound
ascii property on string-literal which would be compiler verified to be ascii and not be vulnerable to unicode normalisation.
let tags = "IHDR".ascii //[73, 72, 68, 82]