Thread overview
Why does inputRangeObject fail to derive correctly for RandomAccessInfinite ranges?
Jul 13, 2022
D Lark
Jul 13, 2022
Paul Backus
Jul 16, 2022
D Lark
Jul 16, 2022
Paul Backus
Jul 16, 2022
D Lark
Jul 16, 2022
D Lark
July 13, 2022

This is slightly related to this issue I reported earlier: https://forum.dlang.org/post/wghdwxptjfcjwptnybhn@forum.dlang.org

Here's the snippet that captures what fails for me

    import std.range: ElementType, isRandomAccessRange, inputRangeObject, sequence, MostDerivedInputRange, RandomAccessInfinite;

    auto seq = sequence!((a, n) => n);
    alias SeqType = typeof(seq);
    static assert(isRandomAccessRange!SeqType);

    static assert(is(MostDerivedInputRange!SeqType == RandomAccessInfinite!(ElementType!SeqType)));

    auto seqInputRange = seq.inputRangeObject;
    static assert(isRandomAccessRange!(typeof(seqInputRange))); // returns 'false'; I expect this to return 'true' as the most derived type of 'seq' is of 'RandomAccessInfinite' as demonstrated above

I am compiling using dmd v2.100.1

First, please can someone clarify if the behaviour I expect in the last line is consistent with the intention of the library?

I have poked around the source and I can see that the InputRangeObject (the object returned by inputRangeObject derives from the return type of the MostDerivedInputRange template, which as shown above returns the correct interface. However it seems that the implementation of InputRangeObject does not implement enum bool empty = false in the case of the RandomAccessInfinite ranges, which leads to the template isRandomAccessRange returning false.

July 13, 2022

On Wednesday, 13 July 2022 at 01:23:35 UTC, D Lark wrote:

>

First, please can someone clarify if the behaviour I expect in the last line is consistent with the intention of the library?

Yes, it should behave the way you expect. The current behavior is a bug.

I've submitted a report for it here: https://issues.dlang.org/show_bug.cgi?id=23242

July 16, 2022

On Wednesday, 13 July 2022 at 01:40:43 UTC, Paul Backus wrote:

>

On Wednesday, 13 July 2022 at 01:23:35 UTC, D Lark wrote:

>

First, please can someone clarify if the behaviour I expect in the last line is consistent with the intention of the library?

Yes, it should behave the way you expect. The current behavior is a bug.

I've submitted a report for it here: https://issues.dlang.org/show_bug.cgi?id=23242

It looks like the resolution is that this can't be fixed? I'm not sure I understand the conclusion. What does this mean for this part of the library then? Should the RandomAccessInfinite!E interface be removed since it's not fully supported?

July 16, 2022

On Saturday, 16 July 2022 at 08:40:10 UTC, D Lark wrote:

>

On Wednesday, 13 July 2022 at 01:40:43 UTC, Paul Backus wrote:

>

On Wednesday, 13 July 2022 at 01:23:35 UTC, D Lark wrote:

>

First, please can someone clarify if the behaviour I expect in the last line is consistent with the intention of the library?

Yes, it should behave the way you expect. The current behavior is a bug.

I've submitted a report for it here: https://issues.dlang.org/show_bug.cgi?id=23242

It looks like the resolution is that this can't be fixed? I'm not sure I understand the conclusion. What does this mean for this part of the library then? Should the RandomAccessInfinite!E interface be removed since it's not fully supported?

The interface works fine, it's just that the InputRangeObject!R instance itself does not satisfy isRandomAccessRange:

auto seqObj  = sequence!((a, n) => n).inputRangeObject;
RandomAccessInfinite!size_t seqIface = seqObj;

static assert( isRandomAccessRange!(typeof(seqIface))); // interface passes
static assert(!isRandomAccessRange!(typeof(seqObj))); // object fails

So if you code to the interfaces and ignore the concrete type of the range object, you should not have any problems.

July 16, 2022

On Saturday, 16 July 2022 at 08:40:10 UTC, D Lark wrote:

>

On Wednesday, 13 July 2022 at 01:40:43 UTC, Paul Backus wrote:

>

On Wednesday, 13 July 2022 at 01:23:35 UTC, D Lark wrote:

>

First, please can someone clarify if the behaviour I expect in the last line is consistent with the intention of the library?

Yes, it should behave the way you expect. The current behavior is a bug.

I've submitted a report for it here: https://issues.dlang.org/show_bug.cgi?id=23242

It looks like the resolution is that this can't be fixed? I'm not sure I understand the conclusion. What does this mean for this part of the library then? Should the RandomAccessInfinite!E interface be removed since it's not fully supported?

What if infinite-ness is a class/struct level property distinct from empty-ness like const enum bool infinite? It appears to me that this is what we try to achieve by the unfortunate coupling of declaring empty as a manifest constant to denote an infinite range. If we have a distinct convention for declaring infiniteness then for the infinite range case we can insert bool empty(){return false;} (or const enum bool = false) automatically or check agreement. We can even have a mixin like the ImplementLength one that can add both infinite and empty in one go, which might be useful for implementing infinite ranges.

July 16, 2022

On Saturday, 16 July 2022 at 12:40:09 UTC, Paul Backus wrote:

>

On Saturday, 16 July 2022 at 08:40:10 UTC, D Lark wrote:

>

On Wednesday, 13 July 2022 at 01:40:43 UTC, Paul Backus wrote:

>

On Wednesday, 13 July 2022 at 01:23:35 UTC, D Lark wrote:

>

[...]

Yes, it should behave the way you expect. The current behavior is a bug.

I've submitted a report for it here: https://issues.dlang.org/show_bug.cgi?id=23242

It looks like the resolution is that this can't be fixed? I'm not sure I understand the conclusion. What does this mean for this part of the library then? Should the RandomAccessInfinite!E interface be removed since it's not fully supported?

The interface works fine, it's just that the InputRangeObject!R instance itself does not satisfy isRandomAccessRange:

auto seqObj  = sequence!((a, n) => n).inputRangeObject;
RandomAccessInfinite!size_t seqIface = seqObj;

static assert( isRandomAccessRange!(typeof(seqIface))); // interface passes
static assert(!isRandomAccessRange!(typeof(seqObj))); // object fails

So if you code to the interfaces and ignore the concrete type of the range object, you should not have any problems.

Thanks this definitely alleviates the issue somewhat.

However it is definitely surprising that an object which literally derives from an interface cannot be tested to implement said interface. Is this inconsistency not a problem?