Proposal: Numeric literals

[zygoloid]

Derived from #17.

• RFC: https://forums.carbon-lang.dev/t/rfc-numeric-literals/120
• Request for decision: https://forums.carbon-lang.dev/t/request-for-decision-numeric-literals-143/129

[josh11b]

It feels a little difficult to evaluate this proposal without some idea about how we are going to consider the type of the result. At least some statement like: we don't consider the type of the result in this proposal, but we may need to add suffixes in order to give user's control over it.

[zygoloid]

It feels a little difficult to evaluate this proposal without some idea about how we are going to consider the type of the result. At least some statement like: we don't consider the type of the result in this proposal, but we may need to add suffixes in order to give user's control over it.

#144 provides a description of how we might treat the type of the result. But the intention was that we may add suffixes if we pick a different direction, so I'll change the proposal to explicitly mention that.

[josh11b]

It feels a little difficult to evaluate this proposal without some idea about how we are going to consider the type of the result. At least some statement like: we don't consider the type of the result in this proposal, but we may need to add suffixes in order to give user's control over it.

#144 provides a description of how we might treat the type of the result. But the intention was that we may add suffixes if we pick a different direction, so I'll change the proposal to explicitly mention that.

I am willing to say this question is outside the scope of this PR. I didn't see what you changed to the proposal, but I agree that a short mention is enough to resolve any concerns for this PR.

[petrhosek]

Have you considered support for fixed-point types? Would that be in scope for this RFC? This is something we would find valuable in the embedded domain and it's been a recurring request from Fuchsia driver teams. It's why we're investing in the support fixed-point types in Clang for C/C++.

[zygoloid]

Updates based on review feedback.

[zygoloid]

@petrhosek

Have you considered support for fixed-point types? Would that be in scope for this RFC? This is something we would find valuable in the embedded domain and it's been a recurring request from Fuchsia driver teams. It's why we're investing in the support fixed-point types in Clang for C/C++.

The intent of this proposal (and see also #144 for what I'm currently thinking in terms of a semantic model) is that these literals can be used for any integer or rational/real type; that could certainly include fixed-point types (whether added as part of the Carbon core language or by a user library). Are there any specific things you'd like to see handled differently for fixed-point types?

[jonmeow]

Thanks for the changes, just following up on a couple things.

[jonmeow]

Thank you for the changes. I think all my comments are resolved now.

[petrhosek]

@petrhosek

Have you considered support for fixed-point types? Would that be in scope for this RFC? This is something we would find valuable in the embedded domain and it's been a recurring request from Fuchsia driver teams. It's why we're investing in the support fixed-point types in Clang for C/C++.

The intent of this proposal (and see also #144 for what I'm currently thinking in terms of a semantic model) is that these literals can be used for any integer or rational/real type; that could certainly include fixed-point types (whether added as part of the Carbon core language or by a user library). Are there any specific things you'd like to see handled differently for fixed-point types?

I was specifically referring to ISO/IEC TR 18037:2008 which defines fixed-point types analogous to a floating-point types with suffixes for fixed-point literals: r for fract types and k for accum types.

[zygoloid]

I was specifically referring to ISO/IEC TR 18037:2008 which defines fixed-point types analogous to a floating-point types with suffixes for fixed-point literals: r for fract types and k for accum types.

I'm considering type suffixes to be out of scope for this proposal. We might have them, in which case a suffix for fixed-point types might make sense, or we might not have them; #144 suggests a model were we do not have type suffixes. However, if we'd want different syntax prior to the type suffix, that would definitely be in scope here.

[jfbastien]

Coming in late to say: I've read this and like it. I have reservations on "natural" location of separators, but it can be relaxed later.

[josh11b]

This is no longer relevant since we got rid of octal literal constants.

[chandlerc]

Editorial comment -- leaving open for @zygoloid to resolve how he wants.

[chandlerc]

Closing out comments after the decision....

[chandlerc]

Editorial comment -- leaving open for @zygoloid to resolve how he wants.

[chandlerc]

LGTM (as code review, the proposal was accepted)

There is one outstanding editorial comment, let me (or Josh) know if you want a quick check of any resolution.

[jonmeow]

Soft suggestion, you may want to update the proposal to reflect the decision:

1. Update digit separators to _.
   • Note ' as an alternative considered or open question, and refer to the decision.
2. Indicate digit separator placement open question went for alternative 0. Literally, **Decision:** Alternative 0**
3. Adjust "natural" to "conventional" which had come up in decision discussion.

[chandlerc]

Confirming this LGTM with updates reflecting decision.