Purity, @safety, etc., in generic code

Steven Schveighoffer schveiguy at yahoo.com
Sat Feb 23 12:28:42 PST 2013


On Sat, 23 Feb 2013 10:34:18 -0500, deadalnix <deadalnix at gmail.com> wrote:

> On Saturday, 23 February 2013 at 15:16:15 UTC, Steven Schveighoffer  
> wrote:
>> This actually is impossible to do with inout, unless your ranges are  
>> pointers or arrays (believe me, I tried with dcollections).  But that  
>> is not inout's fault, it's because we have no way to specify tail-const  
>> arbitrary types.
>>
>
> I have read what come after, but clearly shouldn't have. This is the  
> interesting thing to discuss. Can you expand on that ? Some code sample ?

OK, here is a simple abstract example (the implementation details are not  
important, just the interface).

class Container(T)
{
    ...
    struct range
    {
       ...
       @property inout(T) front() inout {...}
       void popFront() {...}
       bool empty() const { ...}
    }

    inout(range) opSlice() inout {...}
}

Nice, right?  But it doesn't work, for one simple reason: popFront.

const Container!int cont = new Container!int(...);

auto r = cont[];

foreach(const x; r)
{
    writeln(x);
}

doesn't work!  typeof(r) is const(Container!(int).range), and since  
popFront is not const (and cannot be), you cannot iterate!

What you need is a SEPARATE "const_range" type (this is similar to C++).   
Then opSlice() const will return const_range.

And const range and range are not related, they are separate types.  So  
there is no way to have inout choose the right one!

HOWEVER, if your range is a slice it works beautifully, because you can do  
a tail-inout slice inout(T)[].

Not possible with custom types.

I am working on a plan on how to fix this, because it really annoys me for  
my project so much to duplicate code that I just don't even support const  
ranges or immutable ranges!  I do support immutable and const cursors,  
since those point at one element.

But I have not gotten around to pitching it because I need to come up with  
a really good solution :)  Walter is so sour on any tail-const solution  
 from past attempts that it has to be bullet-proof and easy.

-Steve


More information about the Digitalmars-d mailing list