View mode: basic / threaded / horizontal-split · Log in · Help
October 02, 2012
Re: "IndexType" for ranges
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
October 02, 2012
Re: "IndexType" for ranges
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?
October 02, 2012
Re: "IndexType" for ranges
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
October 02, 2012
Re: "IndexType" for ranges
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.
Next ›   Last »
1 2 3
Top | Discussion index | About this forum | D home