On Wednesday, 29 July 2015 at 12:25:14 UTC, Marc Schütz wrote:
On Tuesday, 28 July 2015 at 21:25:23 UTC, Ivan Kazmenko wrote:
Hello,
I wrap an array into a struct. Then I use alias this to
expose the array functionality. Sadly, range properties of
the array are not forwarded, and so I can't use the struct as
an array with functions from std.algorithm and std.range.
-
import std.range, std.stdio;
struct S {
int[] contents;
alias contents this;
}
void main() {
S s;
writeln(hasSlicing!(S)); // false
}
-
I would like to be able to do that, however.
1. Why exactly hasSlicing (et al.) does not check the alias
this-ed array when it checks the struct?
2. What should I do?
The solution I can think of is to insert the 3-6 range
functions which forward the functionality to the underlying
array, perhaps as a mixin.
Ivan Kazmenko.
`hasSlicing` explicitly checks whether the result of the slice
operator has the same type as the original:
https://github.com/D-Programming-Language/phobos/blob/master/std/range/primitives.d#L1499-L1500
If you remove the `static assert()` and change the next line to
use `auto`, and do the same in the other two places in this
templates, it will work.
Thank you, the matter got clearer after reading the right piece
of code and your explanation.
By the way, the documentation around these source lines always
repeats a slightly outdated version of the unittests. Shouldn't
it be brought in sync, perhaps by using the modern DRY way:
///
unittest {...}
Or will that necessarily precede the unittest with Example:?
At any rate, I doubt the ~20 lines of introspection code - which
sometimes gets outdated - should appear at all in hasSlicing et
al. documentation. If a developer encounters problems with
hasSlicing and needs the source, a link to the up-to-date source
itself may be enough.
I don't know whether this is intentional. I'd say we should
allow a sliceable range to have slices of a different type.
EDIT:
The documentation even says that it's intentional, but gives no
justification.
I don't know why the type should be the same, but that may well
be needed.
Anyway, after more digging, I found out I only need to implement
save() to satisfy isRandomAccessRange, which makes sense when I
think of it: the save() for arrays returns an array and not my
struct. And opSlice(...) to satisfy hasSlicing, which also makes
sense if we accept that the slice needs to be the same type: a
generic opSlice is not possible since operator overloads must be
member functions, and even if it were, it would not know how to
construct an object of our specific type in the general case.
So, that's some boilerplate, but its appearance seems justified.
Here's the working code I got:
-
import std.algorithm, std.random, std.range, std.stdio;
struct S {
int[] contents;
alias contents this;
@property auto save() {return S(contents.dup);}
auto opSlice(size_t lo, size_t hi) {return
S(contents[lo..hi]);}
}
void main() {
S s;
s = [4, 3, 2, 1];
writeln(s[1..3]); // [3, 2]
writeln(isInputRange!(S)); // true
writeln(isForwardRange!(S)); // true
writeln(isBidirectionalRange!(S)); // true
writeln(isRandomAccessRange!(S)); // true
writeln(hasSlicing!(S)); // true
auto t = s;
sort(s);
writeln(s); // [1, 2, 3, 4]
randomShuffle(s);
writeln(s); // random permutation
writeln(t); // same as above
}
-
Now, if I remove the custom opSlice and alter the checks in
hasSlicing as you suggested, I get the error:
-
sorting.d(1160): Error: quickSortImpl (S r, uint depth) is not
callable using argument types (int[], uint)
-
Which means quickSortImpl (S r, uint depth) can't instantiate and
call quickSortImpl (int[] r, uint depth) for recursively sorting
its slices. That is understandable.
