DMD 0.177 release

Andrei Alexandrescu (See Website For Email) SeeWebsiteForEmail at erdani.org
Fri Dec 15 17:57:50 PST 2006


Kevin Bealer wrote:
> This is really interesting stuff.  You've probably seen these already but lately D
> has gotten some compile time introspection stuff via tuples, in particular I'm
> thinking of (http://www.digitalmars.com/d/tuple.html) and
> (http://www.digitalmars.com/d/phobos/std_traits.html), which I think look quite
> useful.

I'm familiar with those :o).

> So I'm imagining a case of "meta-ident", which is to say, a template cousin of the
> ident test, applying the 'wrapper' concept to metaprogramming instead of
> programming.  Knowing only the name of a method of a parameter class method
> (T::run), I want to duplicate it's signature in a template class method (A::meta).
[snip]
> Looking just at meta1, I'm wondering if it can absorbs the LValue-ness (inout
> qualification) through the Tuple.  I'm thinking that it can't.  If the LValue
> return type concept only affects function signatures as you say, then it can't be
> stored in a tuple, right?  Instead it would get the type minus the inout qualifier?

Your observation is correct. It all boils down to this: if "inout" is 
not part of the type system, there are two issues: (1) two overloads 
will always be needed to catch it (the similar way it's needed to 
overload the same function on const/non-const), and also (2) 
compile-time introspection would be more complicated as you need to 
"catch" the inout part of the parameter separately - the type won't be 
part of it.

> It seems like this local case could be solved by making ReturnType!() and
> ParameterTypeTuple!() into language attributes, so that they could see the fully
> qualified function-signature grade types with passing conventions etc.
> 
>   T::run.return_type_of  meta_all(T::run.parameter_type_of[0..$] x)
>   {
>       // pass all the parameters via some kind of compiler-aware tuple
>       return wrapped.run(x[0..$]);
>   }
> 
> Which could presumably, provide perfect forwarding of T::run() when used in a
> function signature context.
> 
> [Or maybe there's always a conceptual 'leak' in these kinds of systems, and it can
> only be pushed a finite distance toward obscurity with each new language feature.
>  I hope not, but...]

That remains to be seen, but I think the buck stops at functions. The 
problem of duplicating templates for inout (lvalues) and rvalues stays, 
but I have an idea about that, that I might tell about tomorrow.


Andrei



More information about the Digitalmars-d-announce mailing list