Should r.length of type ulong be supported on 32-bit systems?

[Andrei Alexandrescu via Digitalmars-d]

On 09/30/2016 11:58 PM, Walter Bright wrote:
> On 9/30/2016 7:31 PM, Andrei Alexandrescu wrote:
>> https://github.com/dlang/phobos/pull/4827 still allows that but
>> specifies that
>> phobos algorithms are not required to. -- Andrei
>
> A couple instances where a length may be longer than the address space:
>
> 1. large files
> 2. sequences of mathematically generated values
>
> I don't see a particular advantage to restricting hasLength() to be
> size_t or ulong. Whether an algorithm requires the length to be within
> the addressable capabilities of the CPU or not should be up to the
> algorithm.
>
> There is also cause for r.length to return an int even on a 64 bit
> system - it can be more efficient.

Indeed the "I have a dream" cases are quite the lure. The reality in the 
field, however, is that Phobos thoroughly assumes length has type 
size_t. The problem is defining hasLength in ways that are at the same 
time general and that also work is extremely laborious. Just grep 
through  Consider:

1. std.algorithm.comparison:1007 (abridged)

         const rc = mulu(r, c, overflow);
         if (_matrix.length < rc)

So here we assume length is comparable for inequality with a const 
size_t. That should probably rule out signed integrals.

2. ibid, 1694 (abridged)

     static if (hasLength!(Range1) && hasLength!(Range2))
     {
         return r1.length == r2.length;
     }

Here we assume any two ranges satisfying hasLength have lengths 
comparable for equality. That projects a rather tenuous definition of 
hasLength: "the range must define a length that is comparable for 
equality with any other range that also defines a length". Not 
impossible, but definitely not what we have right now, de facto or de jure.

3. ibid, 634 (abridged)

             immutable len = min(r1.length, r2.length);

So here two lengths must be comparable for ordering, have a common type, 
and have an immutable constructor.

4. ibid, 656 (abridged)

         return threeWay(r1.length, r2.length);

Here threeWay takes two size_t. So both lengths must be at least 
convertible implicitly to size_t.

I got to the end of the first file I scanned with grep, and I don't know 
what a robust definition of hasLength should be - outside of size_t 
itself. The more locations one examines, the more the capabilities 
required get closer to those of size_t - or the more latent bugs exist 
in phobos if we want to support something else.

We have two options here.

1. Support a range of types (e.g.: any integral and any user-defined 
type that supports the following list of primitives: ...) for length 
with hasLength, and then have each range-based algorithm define its own 
additional restrictions if they have such. That means right now a bunch 
of phobos code is incorrect and needs to be fixed.

2. Require lengths to be size_t.

I'm all for generality, but of the useful kind. It seems to me 
supporting a complicated definition of length is a protracted 
proposition with little upside. That's why I'm going with the 
engineering solution in the PR.


Andrei