Proposal: Numeric literals #143
Conversation
There was a problem hiding this comment.
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. |
|
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: |
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. |
|
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. |
| @@ -230,40 +375,43 @@ Con: | |||
| - `0O17` is easily mistaken for `0017` | |||
There was a problem hiding this comment.
This is no longer relevant since we got rid of octal literal constants.
There was a problem hiding this comment.
Editorial comment -- leaving open for @zygoloid to resolve how he wants.
| @@ -230,40 +375,43 @@ Con: | |||
| - `0O17` is easily mistaken for `0017` | |||
There was a problem hiding this comment.
Editorial comment -- leaving open for @zygoloid to resolve how he wants.
There was a problem hiding this comment.
Soft suggestion, you may want to update the proposal to reflect the decision:
- Update digit separators to
_.- Note
'as an alternative considered or open question, and refer to the decision.
- Note
- Indicate digit separator placement open question went for alternative 0. Literally,
**Decision:** Alternative 0** - Adjust "natural" to "conventional" which had come up in decision discussion.
This proposal specifies lexical rules for numeric constants in Carbon.
Adds a decision and rationale for proposal #143. Co-authored-by: Jon Meow <[email protected]>
TODO: -- tests for invalid literals
This proposal specifies lexical rules for numeric constants in Carbon.
Adds a decision and rationale for proposal #143. Co-authored-by: Jon Meow <[email protected]>
[Proposal #143: Numeric literals](https://github.com/carbon-language/carbon-lang/blob/trunk/proposals/p0143.md) added digit separators with strict rules for placement. It missed some use-cases. In order to address this, remove placement rules for numeric literals. Related issue: #1485 Co-authored-by: Chandler Carruth <[email protected]> Co-authored-by: Richard Smith <[email protected]>
Derived from #17.