inout template parameter, or a solution to the templated container issue

[deadalnix]

On Wednesday, 12 June 2013 at 12:37:13 UTC, monarch_dodra wrote:
> OK, but how do you handle methods that rely on T being 
> (potentially) mutable? For example:
>
> //----
> struct Foo(inout T)
> {
>     T a;
>     static if (isAssignable!T) //So here, "T" is actually 
> "inout T", correct?
>     {
>         void opAssign(T other)
>         {a = other.a;}
>     }
> }
> //----
>

T is not assignable. If it were, you couldn't cast implicitly to 
Foo!const(T) . You can still return a T by reference, the caller 
know if it is mutable or not.

> Or is the idea that when instantiated with a "const T", non 
> const methods are not compiled in for that instantiation...?
>
> What about:
>
> //----
> struct Foo(inout T)
> {
>     T[10] buffer;
>     size_t i = 0;
>     ref T get() const {return buffer[i];}
>     void setIndex(size_t i){this.i = i;}
> }
> //----
>

Foo's type qualifier turtle down to inout parameter type 
qualifier. You are returning a ref to a const(T) not a ref T. 
This is a compile time error.

If you don't put const, then T's type is known by the caller, and 
the code is correct.

> I haven't thought through the implications, but it looks like 
> there is a little something missing to make it work.
>

Yes, details may need to be sorted out.

> I DO like your proposition a lot. Being able to have templates 
> that are all instanciated based on the Unqualed type is 
> definitly a plus.