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.

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.

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.

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.

On Wednesday, 29 July 2015 at 23:54:29 UTC, Ivan Kazmenko wrote:
> 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:
>>> ...

Perhaps I still don't implement save() correctly.
The line
    @property auto save() {return S(contents.dup);}
was meant to be just:
    @property auto save() {return S(contents);}
But with either of them, I get an error when trying a function using save.

-----
import std.algorithm, std.range, std.stdio;
struct S {
    int[] contents;
    alias contents this;
    @property auto save() {return S(contents);}
    auto opSlice(size_t lo, size_t hi) {return S(contents[lo..hi]);}
}
void main() {
    S s;
    s = [4, 3, 2, 1];
    nextPermutation(s);
}
-----

The error is:
-----
sorting.d(2460): Warning: use std.algorithm.reverse instead of .reverse property
sorting.d(2460): Error: function expected before (), not _adReverse(range.contents, 4u) of type int[]
-----

So, is something wrong with my save()?

Anyway, I reckon nextPermutation itself is wrong and should use
        reverse(range);
instead of
        range.reverse();
as it does ten lines later:
https://github.com/D-Programming-Language/phobos/blob/30e4ff1717d6d3eb82d2cb0e00a3c07af4263a7b/std/algorithm/sorting.d#L2468-L2478

If anybody can confirm that, I can file an issue and a patch.