`size_t` equivalent

[nigeltao]

What's the Carbon equivalent of C++'s size_t? What is n's type in n = sizeof(T)?

https://github.com/carbon-language/carbon-lang/tree/trunk/docs/design#integer-types only lists fixed-width integer types. It also goes on to say "Values which can never be negative, like sizes, but for which wrapping does not make sense should use signed integer types." So the recommendation is... to use i64??

[chandlerc]

A (huge) open question is whether and how to support different bit-width platforms (specifically 32-bit and 64-bit). Doing so seems both very important for some users, but also likely to introduce a significant amount of complexity into the language and writing things like generics.

Our current approach has been to get a reasonably solid shape to the language as a whole without solving this, and largely assuming a 64-bit environment. And then to look specifically at what we would need to do to introduce the needed flexibility to support 32-bit platforms so that we can have a very concrete understanding of the cost we're undertaking. Beyond understanding the cost, I somewhat hope that we may be able to minimize the cost as well.

Personally, given the (very long) time horizon for Carbon to become useful in any kind of production context, I worry about the cost/benefit tradeoff we will end up with. There may be very few platforms that actually use the 32-bit support of Carbon by the time it is real, and we may have taken a large complexity cost in the language to support it.

But there are clearly enough users of 32-bit platforms that we simply can't dismiss it.

Hence the strategy of trying to minimize and understand the cost, and get as much as we can without it.

Does that make sense? Is this issue useful to leave open -- maybe if you're interested in starting to explore what it would look like to introduce this into Carbon now? Otherwise, maybe best to close as "later".

[nigeltao]

I'm happy to close this as "later", if that's the convention for what "open issue" means on the carbon-lang issue tracker.

For context, I had some simple C code, which contained this snippet:

typedef struct {
  uint8_t* ptr;
  size_t len;
} buffer;

I wondered what my C program would look like in Carbon and tripped up on translating the size_t type. I suppose that, in Carbon, I can work around this for now with alias size_t = i64; and keep going...

...to the next obstacle, in that I can't actually do much with ptr if Carbon doesn't allow pointer arithmetic, and Carbon Slices are TODO. But that's drifting off-topic for size_t discussions.

[nigeltao]

explore what it would look like to introduce this into Carbon now?

A suggestion (which you are obviously free to ignore) is to put alias size_t = i64; into the prelude (or equivalent) for now with the understanding that this is all TBD.

Even if the eventual decision is "only support 64-bit", it might still be useful to keep that alias. In Go, rune is just an alias for int32 but we still use the rune type name in places to explicitly call out that we're dealing with Unicode, not arbitrary integers. ("Rune" is Plan 9's shorter name for "a Unicode code point").

[github-actions[bot]]

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.