Numeric type literal syntax #2015

paulfryzel · 2022-08-12T19:21:54Z

This proposal aims to add a literal syntax for fixed-sized numeric types: integers, unsigned integers, and floating-point numbers.

Related issue: #1998

proposals/p2015.md

josh11b · 2022-08-16T17:13:21Z

proposals/p2015.md

+#### Syntax example use in arbitrary fixed-size numeric types
+
+In the more general case, this syntax can express N-width types.
+
+- `iN` for `Carbon.Int(N)`, An N-width two’s complement signed integer type
+- `uN` for `Carbon.UInt(N)`, An N-width unsigned integer type
+- `fN` for `Carbon.Float(N)`, An N-width IEEE 754 floating-point number type


I personally feel like we should limit the short syntax to the common sizes. The only use case I am aware of for things like i3 are for bit fields, and I feel like adding them to the language before we have a design for bit fields is premature. Furthermore, I think there are big benefits to limiting the syntax:

The compiler can reject typos like i23, i15, etc.

i1, i2, ... currently appear in C++ code in practice, examples:

https:/google/googletest/blob/main/googlemock/include/gmock/gmock-matchers.h#L878

https://chromium.googlesource.com/external/github.com/abseil/abseil-cpp/+/HEAD/absl/container/btree_test.cc#2772

https://sourcegraph.com/search?q=context:global+lang:c%2B%2B+%5Ei1%24+type:symbol&patternType=regexp&case=yes

Rules for other sizes are different, for example, we can't support pointers to arbitrary bits.

Potential for confusion: i1 and il, i18 and i18n

I think this is a case where we should carefully consider the alternatives and have a clear rationale for the choice we make.

I agree with this as well. As you stated, limiting to common sizes removes a bunch of visual confusion in the type names and only affects relatively fringe type cases. Do you think this should be reflected here in this proposal at all? Perhaps a note around this section? Or would it be more appropriate to remove it completely?

I feel like as this is a proposal centered around the syntax, it's not unreasonable to have this material covered here for the future, as long as it's clear to the reader.

I'd suggest starting with multiples of 8 for integer types, but allowing all multiples of 8 (other than 0). LLVM has really good support for this in most operations, it only struggles with things like division and a few other oddities. We should (IMO) consider adding limits when we need to rather than front-loading them here, and I think that restriction should be on the aliased thing (Carbon.Int(102400) or however its spelled), not on the literal syntax.

I'd actually suggest following the same pattern for floating point literals as well. While we'll immediately need to restrict the set of Carbon.Float(N) types to the values of N we can implement, the restriction should be there in the library and not in the literal syntax IMO.

proposals/p2015.md

josh11b

I've tried to identify the text that should be updated to reflect supporting multiples-of-8 bit widths.

proposals/p2015.md

Co-authored-by: josh11b <[email protected]> Co-authored-by: Richard Smith <[email protected]>

josh11b

I think this is in good shape! Once you address these suggestions, please ping the Carbon leads for final approval.

josh11b · 2022-09-06T21:24:46Z

proposals/p2015.md

+### Syntax examples and considerations
+
+These examples are not meant to be formal mappings. They are only used to
+illustrate to the reader how the numeric type syntax may connect to the
+underlying language semantics in future numeric type additions.
+
+#### Syntax example use in common fixed-size numeric types
+
+[As proposed by @chandlerc](https:/carbon-language/carbon-lang/issues/543#issuecomment-845620894),
+our heuristic for type qualification here will be "Any truly pervasive
+non-aggregate/composite/compound type that is also fundamentally
+size-parameterized."
+
+These fixed-width sizes can naturally cover the common register widths of 8-,
+16-, 32-, 64-, and 128-bits, as seen in other languages.
+
+Which expands to:
+
+- `i8`, `i16`, `i32`, `i64`, and `i128` keyword aliases for
+ `Carbon.Int(N={8,16,32,64,128})`
+- `u8`, `u16`, `u32`, `u64`, and `u128` keyword aliases for
+ `Carbon.UInt(N={8,16,32,64,128})`
+- `f16`, `f32`, and `f64` keyword aliases for `Carbon.Float(N={16,32,64})`
+
+Additionally, other type sizes may be available, depending on the platform (for
+example, [x86](https://en.wikipedia.org/wiki/X86)), such as `f80`, `f128`, or
+`f256`.
+
+#### Syntax example use in arbitrary fixed-size numeric types
+
+In the more general case, this syntax can express N-width types.
+
+- `iN` for `Carbon.Int(N)`, An N-width two's complement signed integer type
+- `uN` for `Carbon.UInt(N)`, An N-width unsigned integer type
+- `fN` for `Carbon.Float(N)`, An N-width IEEE 754 binary floating-point number
+ type


I'm not sure what these sections are adding, particularly now that there are not differences between "common" and "arbitrary" sizes.

Yeah, that's fair, and I agree. I'm going to remove both of these sections.

proposals/p2015.md

Co-authored-by: josh11b <[email protected]>

paulfryzel · 2022-09-07T22:14:23Z

@carbon-language/carbon-leads I think we're all set here but of course, always welcome any additional feedback. Please give this a final review/approval when you have the chance.

zygoloid

Looks great to me, thanks!

zygoloid

Approving on behalf of leads.

A few changes: - Merge content from the `primitive_types.md` design doc into the overall design `README.md` since there was so much overlap and no need for two copies. - Consistently spell integer types `Carbon.Int(N)` and `Carbon.UInt(N)`, including the `Carbon.` prefix and avoiding `Unsigned(N)`. - Consistently use a comprehensive set of floating-point types. - Incorporates #2015 into the design docs.

…teral-syntax' of https:/avicorp/carbon-lang into Design-updates-for-carbon-language#2015-numeric-type-literal-syntax

Edit numeric literal design for the literal type proposal and add reference where #2015 was mentioned. Closes #2159 Co-authored-by: Richard Smith <[email protected]> Co-authored-by: josh11b <[email protected]>

paulfryzel requested a review from a team August 12, 2022 19:21

paulfryzel force-pushed the proposal-numeric-type-literal branch from 68f713a to ce1d828 Compare August 12, 2022 19:22

paulfryzel added proposal A proposal proposal draft Proposal in draft, not ready for review labels Aug 12, 2022

paulfryzel marked this pull request as ready for review August 16, 2022 05:03

github-actions bot added proposal rfc Proposal with request-for-comment sent out and removed proposal draft Proposal in draft, not ready for review labels Aug 16, 2022

josh11b mentioned this pull request Aug 16, 2022

Primitive types #1975

Merged

josh11b reviewed Aug 16, 2022

View reviewed changes

paulfryzel added 9 commits August 17, 2022 11:41

Filling out template with PR 2015

b18f297

Add first draft of p2015 proposal

17ab459

Update proposal with minor fixes and tweaks

97f5771

Fix pre-commit markdown lint errors

afaec3b

Tweak syntax example structure

7bdadc7

Remove alternatives numbering and extra space

73f6cd4

Use consistent quotes types

4623175

Fix various grammar issues

7329157

Add distinction for platform-specific types

455f800

paulfryzel force-pushed the proposal-numeric-type-literal branch from 9163006 to 455f800 Compare August 17, 2022 15:46

Fix typos and examples

1f45f86

josh11b reviewed Aug 25, 2022

View reviewed changes

proposals/p2015.md Outdated Show resolved Hide resolved

proposals/p2015.md Show resolved Hide resolved

proposals/p2015.md Outdated Show resolved Hide resolved

proposals/p2015.md Show resolved Hide resolved

proposals/p2015.md Outdated Show resolved Hide resolved

josh11b added a commit to josh11b/carbon-lang that referenced this pull request Aug 25, 2022

Update to reflect carbon-language#2015

42f0482

zygoloid reviewed Aug 27, 2022

View reviewed changes

proposals/p2015.md Show resolved Hide resolved

proposals/p2015.md Outdated Show resolved Hide resolved

Apply suggestions from code review

bffc6cb

Co-authored-by: josh11b <[email protected]> Co-authored-by: Richard Smith <[email protected]>

josh11b added a commit to josh11b/carbon-lang that referenced this pull request Aug 30, 2022

Update to reflect carbon-language#2015

a065a89

paulfryzel added 2 commits August 30, 2022 10:41

Update with input from PR comments

89a4a54

Add note about support for large bit sizes

d81c33c

josh11b reviewed Sep 6, 2022

View reviewed changes

paulfryzel and others added 2 commits September 7, 2022 17:50

Apply suggestions from code review

3dde0f8

Co-authored-by: josh11b <[email protected]>

Update w/ review comments from @josh11b

7921043

zygoloid reviewed Sep 8, 2022

View reviewed changes

zygoloid approved these changes Sep 8, 2022

View reviewed changes

zygoloid merged commit 49c9732 into carbon-language:trunk Sep 8, 2022

zygoloid mentioned this pull request Sep 8, 2022

Need design updates for #2015 numeric type literal syntax #2159

Closed

avicorp added a commit to avicorp/carbon-lang that referenced this pull request Nov 13, 2022

numeric literals update carbon-language#2015

30e65ae

avicorp mentioned this pull request Nov 17, 2022

Design updates for #2015 numeric type literal syntax #2410

Merged

avicorp added a commit to avicorp/carbon-lang that referenced this pull request Nov 21, 2022

Merge branch 'Design-updates-for-carbon-language#2015-numeric-type-li…

020590c

…teral-syntax' of https:/avicorp/carbon-lang into Design-updates-for-carbon-language#2015-numeric-type-literal-syntax

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Numeric type literal syntax #2015

Numeric type literal syntax #2015

paulfryzel commented Aug 12, 2022 •

edited

Loading

josh11b Aug 16, 2022

paulfryzel Aug 16, 2022

chandlerc Aug 25, 2022

josh11b left a comment

josh11b left a comment

josh11b Sep 6, 2022

paulfryzel Sep 7, 2022

paulfryzel commented Sep 7, 2022

zygoloid left a comment

zygoloid left a comment

Numeric type literal syntax #2015

Numeric type literal syntax #2015

Conversation

paulfryzel commented Aug 12, 2022 • edited Loading

josh11b Aug 16, 2022

Choose a reason for hiding this comment

paulfryzel Aug 16, 2022

Choose a reason for hiding this comment

chandlerc Aug 25, 2022

Choose a reason for hiding this comment

josh11b left a comment

Choose a reason for hiding this comment

josh11b left a comment

Choose a reason for hiding this comment

josh11b Sep 6, 2022

Choose a reason for hiding this comment

paulfryzel Sep 7, 2022

Choose a reason for hiding this comment

paulfryzel commented Sep 7, 2022

zygoloid left a comment

Choose a reason for hiding this comment

zygoloid left a comment

Choose a reason for hiding this comment

paulfryzel commented Aug 12, 2022 •

edited

Loading