Purity, @safety, etc., in generic code

[deadalnix]

On Saturday, 23 February 2013 at 20:28:43 UTC, Steven 
Schveighoffer wrote:
> 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

Steven would you mind to create a topic on this subject precisely 
?