What type should array / string lengths be?

[TheLoneWolfling]

Just flat-out 64 bits? A defined type?

Currently about half the lengths are ints and about half are longs.

[incrediblesound]

I feel like 64 bits is overkill, do you think we could use size_t?

[TheLoneWolfling]

We could indeed use size_t.

The difficulty there is then what size should integers be?

If we make integers ptrdiff_t, then we introduce different behavior for different platforms w.r.t. integers.

But if we don't make integers size_t, then an array or string's length may be larger than the max integer value. There are platforms where sizeof(ptrdiff_t) < sizeof(long), and there are platforms where sizeof(ptrdiff_t) >= sizeof(long). (Though note that "The types used for size_t and ptrdiff_t should not have an integer conversion rank greater than that of signed long int unless the implementation supports objects large enough to make this necessary.")

Though even with this said, making integers ptrdiff_t and indexes size_t would be my first choice.

Well, or making integers variable-length. Which I could do, if you wanted.

[TheLoneWolfling]

Any more thoughts on this?

[incrediblesound]

tbh this is a bit outside the scope of my knowledge, so I will appreciate anything you add in this domain.

[TheLoneWolfling]

After mulling it over, here's what I'd suggest:

Have huo integers be int64_t. It's overkill, yes, but the next step down is 32 bits, and although you're rather unlikely to allocate 2^63 elements, it's easy to allocate 2^31 elements. And you want them to be of some fixed length (rather than changing with platform) as having them be different widths depending on platform is no fun to deal with at all.

Have indexes be size_t internally. And just have a function to cast between the two of them that throws an error if it would be out of range.