Character Literals (#1934)

[cabmeurer]

Put character literals in single quotes, like 'a'. Character literals work
like numeric literals:

• Every different literal value has its own type.
• The bit width is determined by the type of the variable the literal is
  assigned to, not the literal itself. Follows the plan from Open design idea: character literals #1934.

[cabmeurer]

@opelolo let me know when you want to start collaborating on this

[josh11b]

Sorry for the delay getting back to you on this. GSoC and so on have been keeping me busy.

Looks good! I think this is ready for the leads to review.

[cabmeurer]

@chandlerc could you take another look at this when you have a chance?

[cabmeurer]

@zygoloid could you take a look at this when you have a chance?

[geoffromer]

FYI both @zygoloid and @chandlerc have been on vacation (I think Chandler still is), so it may take them a little while to get to this.

[zygoloid]

Looks good, I'm happy to move forward with this.

[zygoloid]

One consequence appears to be that this is invalid:

fn Digit(n: i8) -> Char32 {
  return '0' + n;
}

... and something like return ('0' as Char32) + n; would be needed instead. I think I'm OK with that, but I expect it to be a minor source of friction as that kind of usage is fairly common in C++.

[josh11b]

Given that '0' + n has a value that is only known at runtime, what type should it be? Using the type of n here is a bit worrisome, due to overflow. I would be fine with saying the result would be Char32, but maybe that would only make sense for some types of n? For example if n: i64, a Char32 result would be surprising.

[chandlerc]

I think I like keeping this super-explicit for now (requiring a cast to a specific sized type). We can try to add better defaults if in practice this friction is something users dislike. I'm somewhat hopeful that instead we can have a really easily discovered (and targeted in migration) API for mapping to digits, and avoid how much this comes up in practice. But it seems easy to address if it does come up.

[chandlerc]

First off, sorry for all the delays while folks were first at a conference, and then on vacation, and then catching up! I know that really stretched things out way more than we'd like for this proposal, and I appreciate you bearing with us.

Hopefully things will move (much) more steadily now.

---

On this proposal, I'm pretty happy moving forward here too. =] Thanks so much for the work on this!

All my comments below are just around wording, clarifications, etc. At least, I don't think there are any suggestions for a substantive change here. Hopefully with help from folks we can converge quickly on the remaining wording issues and land this.

[chandlerc]

I think I like keeping this super-explicit for now (requiring a cast to a specific sized type). We can try to add better defaults if in practice this friction is something users dislike. I'm somewhat hopeful that instead we can have a really easily discovered (and targeted in migration) API for mapping to digits, and avoid how much this comes up in practice. But it seems easy to address if it does come up.

[chandlerc]

Looks great, thanks so much! Merging!

[cabmeurer]

Thank you everyone!