The protocols are a bit of a mess right now, especially the _Builtin ones, and we'd like to fix this all up prior to ABI stability to avoid compatibility hacks, or very soon after with compatibility hacks. I'm currently laser-focused on substantial ABI changes for String at the moment (essential for better byte-string-like support in the future, but way outside the scope of this thread). But, I will try to help as much as I can.
I haven't followed all of the earlier talk on this thread, or paged in all of the protocols recently, but I could see something like this making sense:
| ExpressibleByCharacterLiteral | ExpressibleByStringLiteral | |
|---|---|---|
| FixedWidthInteger |  |
 |
| Unicode.Scalar | |
|
| Character | |
|
| String | |
|
Just as with integer literals, the compiler does overflow checking when it can. FixedWidthInteger character literals only support single-scalar graphemes and need enough bit-width to encode the scalar value. The compiler continues to do a bestminimal-effort job of ensuring Character conformance to either ExpressiblyBy* is probably a single grapheme. Examples:
| UInt8 | UInt16 | UInt32 | Unicode.Scalar | Character | |
|---|---|---|---|---|---|
| 'x' | 120 | 120 | 120 | U+0078 | x |
| '花' |  |
33457 | 33457 | U+82B1 | 花 |
| '𓀎' | |
|
77838 | U+1300E | 𓀎 |
' ' |
|
|
|
|
|
| 'ab' | |
|
|
|
|
I haven't thought about what to do about signed integers when the value ends up setting the sign bit. We'd probably want to just produce the negative number, but perhaps there's an argument to error.