Reflect "Numeric literal semantics #144" in the design docs

[josh11b]

Proposal #144 was accepted but the design docs in https:/carbon-language/carbon-lang/tree/trunk/docs/design have not been updated to reflect its acceptance.

[Pritjam]

Hi, I'd like to work on this issue. Can it be assigned to me?

[josh11b]

Sure, I've assigned it to you. Feel free to ask me questions if you need help.

It would be reasonable to create a new file for this content, like /docs/design/numeric_literals.md, or modify the existing file /docs/design/primitive_types.md, though note I was planning on deleting primitive_types.md in #1975 since it currently is just a sketch and not providing value beyond what is in the overview. It is absolutely fine to copy content from #144 into the document you are writing whenever that is convenient.

You should make sure that this document:

• is linked from the relevant sections from the design overview: integer literals and floating-point literals
• has a "references" section that links to Numeric literal semantics #144 (and any other relevant proposals like Proposal: Numeric literals #143 or String literals #199 )

[josh11b]

Also note that /docs/design/lexical_conventions/numeric_literals.md has the official description of how numeric literals are written lexically in the source code (added in #185 ).

[Pritjam]

I want to make sure I'm understanding these types correctly. From reading through proposal #144, it looks like every number has a different type. For example, the type of the literal 3 is different from the type of the literal 4. Furthermore, the type of the literal 3.0 is different from that of 3. Is that correct?

Another question: In the Implicit Conversions section of #144, we bring up the idea of IntLiteral(n). What does n represent here? Is it the bit-width of the integer type (so something like 32 or 16) or is it the value of the IntLiteral itself?

[josh11b]

It is the value of the IntLiteral itself. So the type of the literal 3 is IntLiteral(3) which is different from the type of the literal 4, which is IntLiteral(4).

[Pritjam]

Makes sense. I had another question about the Implicit Conversions, now that that's clarified. The code for converting an IntLiteral(N) to a different sized integer type references Int(M). Here, does M represent bit width? Otherwise, things like Int(M).MinValue and Int(M).MaxValue don't really make sense.

Edit: Never mind, after reading the overview looks like this is correct.

[josh11b]

Yes, the M in Int(M) is a bit width.

[Pritjam]

Sorry for the delay, I was caught up in finishing another PR and couldn't update you on the progress on this one. I've drafted a design document for numeric literals. Please take a look at it in my fork and let me know what you think! I used the primitive_types.md doc as a starter, so a few parts (the Open Questions section for one) come straight from there.

I also added references to this document from the readme in the integer literals and floating-point literals sections.

[josh11b]

I wouldn't start from primitive_types.md, all that content is being deleted in #1975 . For example, the goal of this PR is to write something that isn't provisional, and so shouldn't include the provisional text that was in primitive_types.md. As an example, the "TODO" section is saying the opposite of what you should be saying. If you want more feedback, you should send a PR, which are designed for review, including showing diffs and allowing suggestions to be attached to specific lines.

[Pritjam]

I will go ahead and make a PR so we can properly have suggestions. The reason I had the TODO section is because many of the other design docs I read as examples had the TODO section in the beginning, so I assumed it was boilerplate for newer and less reviewed articles. I've now deleted the TODO section.

Also, I was unclear when I used primitive_types.md as a starter--what I mean there was I used primitive_types.md as a reference for the general structure of the document. All of the content comes from proposal #144.

The PR I've created is #2092.

[josh11b]

I've left comments on #2092 . I know I put in a lot of suggestions, but don't worry that is completely expected when first contributing to Carbon. Honestly, we need to do some work to make these detailed design documents more consistent, they have been added over a longish period of time where we have changed our minds about what should be included.

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