Implement numeric types

[jonmeow]

#700 renamed to i32, but left out the rest of the numeric types noted in #543. That is iN, uN, and fN for N in (8, 16, 32, 64). We should implement these.

It may be good to treat #766 as blocking this, so that any implementation is closer to what we expect long-term.

edit: noting a few specific comments on implementation approach:

• Need a Byte type: Implement numeric types #767 (comment)
• Rough implementation overview: Implement numeric types #767 (comment)
• start with mapping i32 to a prelude type (could even be Int32, non-generic): Implement numeric types #767 (comment)

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

[matthew-russo]

I was looking at picking this up but saw that it may be blocked on #766 which is further blocked on #742. Just wanted to do a pulse check on the status of this issue in relation to dependency on others. It seems like basic prelude functionality is in place (https://github.com/carbon-language/carbon-lang/blob/trunk/explorer/syntax/prelude.cpp#L11-L24) without a full implementation of imports

[jonmeow]

I added a note on #766. The current prelude functionality is enough to implement things. We do need library support though to make sure it doesn't become a giant file, but I don't think that's an immediate concern.

[matthew-russo]

I see #1998 was cut for a formal proposal on numeric types so I'm going to leave this until things have been finalized through a proposal.

[jonmeow]

FWIW, that issue is really about the names, and the leads already made a decision. There's a separate unresolved (and untracked I think) question about the shape of the underlying types, but I think the i32 -> Int(32) mapping plan is pretty likely, it's really only the nuances that need to be designed. A draft implementation in explorer can help with that; it's unlikely the details would diverge so much as to completely rewrite an implementation.

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

[jonmeow]

Note, in recent discussion about this, I think we were thinking what's missing for this to happen is some kind of raw storage type, e.g. Byte to have arrays of Byte. Then Int(32) would have an array of Bytes internally for storage. It would likely still need builtins for operations, but the comparisons and such could be implemented as intended with generic interfaces that call the builtins instead of straight C++ code as i32 is today. The intent is that that model would then be extended for i8 -> Int(8), i16 -> Int(16), and so on.

[priyans-google]

I can take a stab at this. Rough outline:

Parser:

• Generalize IntTypeLiteral to NumericTypeLiteral<BaseType>(size). Propagate both the basetype and size.

Interpreter:

• Add new Value kinds NumericalType and NumericalValue to generalize from IntType and IntValue
• Distinguish between different numeric types in the type checker.
• Change interpreter.cpp to properly handle each operator.

There are a ton of details which I need to understand.