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.