Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal: Numeric literals #143

Merged
merged 1 commit into from
Oct 6, 2020
Merged

Proposal: Numeric literals #143

merged 1 commit into from
Oct 6, 2020

Conversation

zygoloid
Copy link
Contributor

@zygoloid zygoloid commented Aug 14, 2020

@zygoloid zygoloid added WIP proposal A proposal labels Aug 14, 2020
@googlebot googlebot added the cla: yes PR meets CLA requirements according to bot. label Aug 14, 2020
@zygoloid zygoloid changed the title Numeric literals Proposal: Numeric literals Aug 14, 2020
@zygoloid zygoloid added proposal rfc Proposal with request-for-comment sent out and removed WIP labels Aug 14, 2020
Copy link
Contributor

@josh11b josh11b left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

proposals/p0143.md Show resolved Hide resolved
proposals/p0143.md Outdated Show resolved Hide resolved
@zygoloid
Copy link
Contributor Author

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.

proposals/p0143.md Outdated Show resolved Hide resolved
proposals/p0143.md Outdated Show resolved Hide resolved
proposals/p0143.md Outdated Show resolved Hide resolved
proposals/p0143.md Outdated Show resolved Hide resolved
proposals/p0143.md Outdated Show resolved Hide resolved
proposals/p0143.md Outdated Show resolved Hide resolved
proposals/p0143.md Outdated Show resolved Hide resolved
proposals/p0143.md Outdated Show resolved Hide resolved
proposals/p0143.md Outdated Show resolved Hide resolved
proposals/p0143.md Show resolved Hide resolved
proposals/p0143.md Show resolved Hide resolved
proposals/p0143.md Show resolved Hide resolved
proposals/p0143.md Outdated Show resolved Hide resolved
proposals/p0143.md Outdated Show resolved Hide resolved
proposals/p0143.md Outdated Show resolved Hide resolved
proposals/p0143.md Show resolved Hide resolved
proposals/p0143.md Outdated Show resolved Hide resolved
@josh11b
Copy link
Contributor

josh11b commented Aug 19, 2020

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
Copy link

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++.

proposals/p0143.md Outdated Show resolved Hide resolved
proposals/p0143.md Outdated Show resolved Hide resolved
proposals/p0143.md Show resolved Hide resolved
proposals/p0143.md Outdated Show resolved Hide resolved
proposals/p0143.md Outdated Show resolved Hide resolved
Copy link
Contributor Author

@zygoloid zygoloid left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updates based on review feedback.

@zygoloid
Copy link
Contributor Author

@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?

Copy link
Contributor

@jonmeow jonmeow left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

proposals/p0143.md Show resolved Hide resolved
proposals/p0143.md Outdated Show resolved Hide resolved
proposals/p0143.md Outdated Show resolved Hide resolved
proposals/p0143.md Outdated Show resolved Hide resolved
Copy link
Contributor

@jonmeow jonmeow left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

proposals/p0143.md Show resolved Hide resolved
proposals/p0143.md Outdated Show resolved Hide resolved
proposals/p0143.md Outdated Show resolved Hide resolved
@petrhosek
Copy link

@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
Copy link
Contributor Author

zygoloid commented Sep 2, 2020

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
Copy link

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`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

proposals/p0143.md Show resolved Hide resolved
Copy link
Contributor

@chandlerc chandlerc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Closing out comments after the decision....

proposals/p0143.md Show resolved Hide resolved
proposals/p0143.md Outdated Show resolved Hide resolved
proposals/p0143.md Outdated Show resolved Hide resolved
proposals/p0143.md Show resolved Hide resolved
proposals/p0143.md Outdated Show resolved Hide resolved
@@ -230,40 +375,43 @@ Con:
- `0O17` is easily mistaken for `0017`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

proposals/p0143.md Show resolved Hide resolved
Copy link
Contributor

@chandlerc chandlerc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 jonmeow added proposal accepted Decision made, proposal accepted and removed needs decision proposal rfc Proposal with request-for-comment sent out labels Sep 23, 2020
Copy link
Contributor

@jonmeow jonmeow left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

@chandlerc chandlerc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Confirming this LGTM with updates reflecting decision.

This proposal specifies lexical rules for numeric constants in Carbon.
@zygoloid zygoloid merged commit fb7aa6d into carbon-language:trunk Oct 6, 2020
@jonmeow jonmeow deleted the proposal-numeric-literals branch October 6, 2020 15:50
chandlerc added a commit that referenced this pull request Oct 16, 2020
Adds a decision and rationale for proposal #143.

Co-authored-by: Jon Meow <46229924+jonmeow@users.noreply.github.com>
zygoloid added a commit that referenced this pull request Nov 4, 2020
Add design text based on the contents of two proposals:

#142 Unicode source files
#143 Numeric literals
zygoloid added a commit that referenced this pull request Feb 12, 2021
chandlerc pushed a commit that referenced this pull request Jun 28, 2022
This proposal specifies lexical rules for numeric constants in Carbon.
chandlerc added a commit that referenced this pull request Jun 28, 2022
Adds a decision and rationale for proposal #143.

Co-authored-by: Jon Meow <46229924+jonmeow@users.noreply.github.com>
chandlerc pushed a commit that referenced this pull request Jun 28, 2022
Add design text based on the contents of two proposals:

#142 Unicode source files
#143 Numeric literals
zygoloid added a commit that referenced this pull request Aug 25, 2022
[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 <chandlerc@gmail.com>
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cla: yes PR meets CLA requirements according to bot. proposal accepted Decision made, proposal accepted proposal A proposal
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants