SE-0243: Codepoint and Character Literals

[lorentey (Karoy Lorentey)]

@Nevin

Furthermore, with the proposal in its current form, 'a' * 'a' would be valid Swift (after a zero-effort user-supplied conformance, which is only required for ABI reasons), expressing the multiplication of 97 by itself as an integer. So if you think “ 'a' * 'a' ” is objectionable, then it follows that the current proposal is as well.

Oh. That's unfortunate. I actually did not realize the proposal would allow that. (This isn't immediately obvious from the proposal text, and it's only tangentially implied by a test in the implementation.)

Searching back, I now see this did come up during the pitch. I'm sorry I missed it:

@xwu

However, I certainly don't find the use case of shorthands for UInt(ascii:) compelling. And, yes, I have actually written code that requires such APIs. (In fact, I've thought long enough about this in the past that I renamed a C string API in SE-0134.)

Moreover, some of the examples above show likelihood of active harm in the proposed design. Specifically I would argue that it would be a nonstarter for the proposal if the following behavior didn't hold:

'1' + '1' // "11"
'1' - '1' // Error: binary operator '-' cannot be applied to two 'Character' operands

I wholeheartedly agree with @xwu here.

I accept that there is some utility in using ASCII character literals for the purposes of integer initialization and pattern matching. But I absolutely do object to the prospect of character literals directly appearing in arithmetic expressions like 'a' + 12, much less abominations like 'a' * 'a'.

let m1 = ('a' as Int) + 12     // this is (barely) acceptable to me
let m2 = 'a' + 12              // ...but this seems extremely unwise
let wat = 'a' * 'b' / 'z'      // ...and this is just absurd

If we cannot prevent the last two lines to compile, then in my opinion the proposed integer conformances should be scrapped altogether.

An argument can perhaps be made to keep the Int8/UInt8 conformances to cater for the parsing usecase, however absurd these expressions might be. But this argument doesn't apply to any other FixedWidthInteger type, so I believe it'd be best if the generic initializer was removed from the proposal.