Open design idea: character literals

[zygoloid]

We currently have no lexical support for character literals. While in principle we could reuse string literals for this purpose, it would make code more self-documenting and readable if we had a distinct lexical syntax for character literals versus string literals. Based on the syntactic choices made in other languages, single-quoted text ('x') seems likely to be the best option here. We need a proposal for this.

One significant open question is how character literals should interact with Unicode: should they represent a single UTF-8 code unit, a single code point, a single grapheme cluster, or something else? The choice seems to depend on what type is being initialized by the literal: for example, something akin to C++'s char8_t would want a single UTF-8 code unit, whereas something akin to C++'s char32_t would want a single Unicode code point, and a Glyph type in a text rendering system may want something more complex, such as a base character plus a sequence of combining characters.

Design idea: Treat character literals exactly the same way as simple string literals but with ' delimiters instead of ". Do not support multi-line literals nor "raw" literals using #'x'#, and do not allow empty character literals to keep ''' unambiguous. As with string literals, each character literal would have a different type.

In a little more detail: a character literal is a ' followed by a sequence of one or more non-newline, non-', non-\ characters and escape sequences, followed by another '. As with string literals, the type of a character literal would depend on its contents, so 'a' and 'b' would have different types, as would 'a' and "a", but '\n' and '\u{A}' would have the same type. No restriction is placed on the number of UTF-8 code units in a character literal, but conversions from character literal type to each kind of character type would be supported only for characters that are representable, in the same way as we restrict integer literals to only convert to integer types in which they are representable.

[opelolo]

Hi @zygoloid I'd love to give this a try but I'm new to open source contribution and I write Python.

Although I have read the issue, I'm not sure I understand what's expected. Could you please link the source code or have some screenshots added for clarity? Thank you

[cabmeurer]

I am also interested in this, @opelolo you can take it if you're still interested. Or if you want we can collaborate.

[opelolo]

Sure @cabmeurer we can work together. Although I am still confused as to what's expected. Do you understand the issue?

[geoffromer]

@opelolo This issue is asking for someone to write up a design of how character literals will work in Carbon, and take it through the proposal process. For previous examples of this sort of work, see #199 (which proposed string literals), and #143/#144 (which proposed numeric literals).

I'd love to give this a try but I'm new to open source contribution and I write Python.

I'd definitely recommend finding a collaborator who's familiar with C++. The main task here is to write a document, not code, but interoperability and migration with C++ is a central focus of Carbon's design. Also, sometimes if there are implementability questions about a proposal, we ask for a proof-of-concept implementation in the Explorer, which is written in C++.

[cabmeurer]

@opelolo feel free to message me on the discord and we can get started!

Edit: Created a draft as per the proposal process

@zygoloid @geoffromer could one of you add the proposal label to draft when you have some time?

[geoffromer]

@zygoloid @geoffromer could one of you add the proposal label to draft when you have some time?

Sure, done!

[Aniumbott]

Hello @geoffromer, I'm good at C++ I can work on this or I can team up with them as well.

[geoffromer]

Hello @geoffromer, I'm good at C++ I can work on this or I can team up with them as well.

I don't think it makes sense to have multiple groups working on this independently, so I think you should coordinate with @cabmeurer and @opelolo.

[github-actions]

We triage inactive PRs and issues in order to make it easier to find active work. If this issue should remain active or becomes active again, please comment or remove the inactive label. The long term label can also be added for issues which are expected to take time.
This issue is labeled inactive because the last activity was over 90 days ago.

[chandlerc]

Fixed with #1964 !