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

[monarch_dodra]

On Wednesday, 12 June 2013 at 06:08:58 UTC, deadalnix wrote:
> ...

I like it!

> The idea popped in my mind yesterday, so it is not really super 
> fleshed out, and I'm not sure if some horrible dark corner case 
> makes it completely worthless. But it seems super promising to 
> me, so I want to share. The current situation isn't satisfying 
> and we desperately need a solution.

Maybe...

> Within the template, T is always seen as inout, and only one 
> instantiation occur for all top type qualifiers. Array!T and 
> Array!const(T) refers to the same instance of Array. As a 
> result, this makes it impossible to specialize Array on T's 
> type qualifier.

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;}
     }
}
//----

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;}
}
//----

This time, the mutable method works, even when T is not mutable :/

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

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.