SE-0243: Codepoint and Character Literals

[taylorswift]

@xwu

Swift does not support f , ul , or other suffixes for numeric literals as found in C; this was a deliberate choice, but I would have to dig for longer to find Chris's post specifically on that topic. Nor did we accept r as a prefix for raw strings; no doubt that discussion is still fresh in your mind.

I will do you one better, however: here is Chris's opinion of this exact idea.

well, Chris didn’t reject it as much as pose a set of questions that needed to be answered for the idea to be viable. That proposal from 2015 was much more expansive (reworking custom operators, extending to numeric literals?) and couldn’t answer those questions. I believe we have answers today in this specific context.

@Chris_Lattner

On the other hand: I haven’t heard this be a wide-spread complaint. It smacks of the “123ull” sorts of suffixes in C, which are pretty grotty IMO. It reduces clarity of code by introducing syntax magic.

I think over time this became a bigger and bigger complaint. just the vibe i’ve been getting around here, though.

the ugliness of the C suffixes comes from the fact that the suffixes are basically abbreviated reproductions of the type names (unsigned long long long long long foo = 123ullllllllllllllllll;) which are visually redundant, but mechanically needed because of C’s loose numeric promotion semantics.

Character literal prefixes on the other hand convey useful information about the value.

// destination type is UInt64, but we know `x` is an ASCII encoded 
// value between 0 and 128
let c:UInt64 = a'x' 
// destination type is UInt32, but we know `x` is an EBCDIC encoded 
// value between 0 and 256
let d:UInt32 = e'x' 

Also, let c:Character = 'x'c instead of let c:Character = "x" isn’t really a boost in clarity, but let c:UInt8 = a'x' instead of let c:UInt8 = .init(ascii: 'x') is, at least when you have lots and lots of ASCII values buried in lots and lots of UInt8(ascii:) initializers in a line.

@Chris_Lattner

1. How does this generalize to integer, FP and other literals we have?

We don’t. We have no need.

@Chris_Lattner

2. How do we avoid baking these into the compiler? We would want to allow the suffixes to be user extensible, and have the standard ones defined by the standard library. For example, “a”c could be sugar for c(“a”) or something.

In the four years since, we can actually conceive of a workable way to making this possible! (though i wouldn’t desugar 'a'c to c('a'), rather, I’d let it be a statically assertable parameter to a @textLiteral initializer.) I’d hop over to the tuple literals thread for some interesting thoughts on a fully flexible compile-time literals system.

@Chris_Lattner

3. There are C extensions that support things like _128 as well, should we support numbers? Keep in mind that integer literals in swift support 123_456_789 separators.

No. We have no need.

@Chris_Lattner

4. Exactly which ones would we add to Swift out of the box? Do we go down the C path of only having them for large ones (but ignores “short”)?

a'x' and u'x'. Others like e'x' could be added through the evolution process, and eventually, users could define their own prefixed text literals with the aformentioned compile-time literals.

The really interesting thing to me is back then, before we had really sat down and thought about how we deal with literals in the language, this idea would have required a lot of weird compiler magic to make it make sense, and the motivation was quite lacking. Both of those premises have changed since then, which is really a testament to how far Swift has come.