Am Sat, 1 Oct 2016 01:04:01 -0400 schrieb Andrei Alexandrescu <[email protected]>:
> 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 Me too, I haven't looked into it, but I noticed that all the points you mentioned are resolved if length was required to be a natural number, i.e. unsigned basic type. Based on these points alone, I tend to agree with Walter. Note: Point 4. is arguable, because `threeWay` is a local function designed to compare char types and only used once to compare lengths under the (silent) assumption that they are < int.max. I.e. It would be cleaner to replace that call with an explicit comparison. -- Marco
