On Tuesday, 2 October 2012 at 17:24:32 UTC, Andrei Alexandrescu wrote:
> Yes. Unfortunately there are few, few cases in which size_t is insufficient (e.g. an input range from a file or a large iota, both on 32-bit builds). I personally think these are too few to need formal support.

I'd throw bit arrays into the mix, where 32 bit can also be quite small. There might also be some other clever hacks using custom index types for representing non-linear data structures as ranges.

The question is whether such ranges are likely to be used as random access ranges. I can't come up with a compelling use case right now, but I'd rather think twice before throwing support for them out of the window and later regretting it. Also, one of the simplest ranges (iota) not fitting the range concept has somewhat of an odd aftertaste.

David

On Tuesday, 2 October 2012 at 18:45:24 UTC, David Nadlinger wrote:
> On Tuesday, 2 October 2012 at 17:24:32 UTC, Andrei Alexandrescu wrote:
>> Yes. Unfortunately there are few, few cases in which size_t is insufficient (e.g. an input range from a file or a large iota, both on 32-bit builds). I personally think these are too few to need formal support.
>
> I'd throw bit arrays into the mix, where 32 bit can also be quite small. There might also be some other clever hacks using custom index types for representing non-linear data structures as ranges.
>
> The question is whether such ranges are likely to be used as random access ranges. I can't come up with a compelling use case right now, but I'd rather think twice before throwing support for them out of the window and later regretting it. Also, one of the simplest ranges (iota) not fitting the range concept has somewhat of an odd aftertaste.

It's easy to think of random access ranges that could easily need more than size_t:

- The cartesian product of several smaller ranges
- a permutationsOf(r) range
- a subsetsOf(r) range

Any combinatoric range would easily use up 32-bit and 64-bit indexing. If 32-bit sometimes isn't enough, then neither is 64-bit.

So, the question is, do we want to allow the use of BigInt indexing?

On Tuesday, October 02, 2012 20:45:36 David Nadlinger wrote:
> On Tuesday, 2 October 2012 at 17:24:32 UTC, Andrei Alexandrescu
> 
> wrote:
> > Yes. Unfortunately there are few, few cases in which size_t is insufficient (e.g. an input range from a file or a large iota, both on 32-bit builds). I personally think these are too few to need formal support.
> 
> I'd throw bit arrays into the mix, where 32 bit can also be quite small. There might also be some other clever hacks using custom index types for representing non-linear data structures as ranges.
> 
> The question is whether such ranges are likely to be used as random access ranges. I can't come up with a compelling use case right now, but I'd rather think twice before throwing support for them out of the window and later regretting it. Also, one of the simplest ranges (iota) not fitting the range concept has somewhat of an odd aftertaste.

If it were restricted to size_t, it would just mean that those types would be restricted to 32-bits for their length and index on 32-bit machines if you would want them to function as ranges (as iota would - if size_t is required, then it's going to use size_t, not become incompatible as a range).

But it's types like this which muddy things a bit. Ideally, we'd insist that all ranges use size_t. It simplifies things and certainly using smaller than that doesn't really make sense. But if we really need to support ulong, then unfortunately, we really need to support ulong - in which case presumably length and indices would have to be size_t or ulong (either that or IndexType.sizeof >= size_t.sizeof, but allowing signed types also complicates things in nasty ways).

It _would_ be great to be able to just insist on size_t though. The question is whether we can reasonably get away with that.

- Jonathan M Davis

On Tue, 02 Oct 2012 19:23:48 +0200
"Jonathan M Davis" <jmdavisProg@gmx.com> wrote:

> On Tuesday, October 02, 2012 19:10:53 monarch_dodra wrote:
> 
> Ideally, only size_t would be allowed. Reality makes it so that we need ulong in some cases (e.g. iota). Given that fact, you'd ideally restrict it to size_t or ulong specfically (or at least IndexType.sizeof >= size_t.sizeof). The problem is that I'm quite sure that there are plenty of programmers out there who have been using int for length and indices even though it's a horribly bad idea. It's a classic mistake.
> 

Yea, typing "int" tends to be automatic enough, and then the awkwardness of "size_t" on top of that tends to ensure it doesn't get used as much as it should.