Tango template/meta world

* core.Tuple has been updated to essentially match std.typetuple. * core.Traits has been moved to util.meta.Traits.

I think we still need something like std.boxer, which should probably live in core. Also, util.meta.Traits still needs expanding to add some features from std.traits.

Did we come to an agreement on Tom's bind?

About std.boxer, there is an Any package in the Doost project, inspired by Boost, may be worth a look?

is boxer really necessary these days? It's always seemed like such a hack :p

I never found it obvious that boxer was useful, but pragma has wished for a beefed up Variant in the forum.

Everything has been finished but some sort of variant type. Tom suggested "Any" as a name for it. I'll ask around and see if someone can come up with a good implementation, or perhaps take a crack at it myself. Can't say I've ever had much us for a variant outside of the occasional quick DB query.

/projects/doost has a Boost.Any port I think - may be of interest for reference at least.

My $0.02 for Variant.

The key motivation for a true-ish Variant type is that D does not allow for overloading the behavior of operators at compile-time. So such operations must be accomplished at run-time instead, which greatly reduces the flexibility of templated and machine-generated code.

It's a little contrived, but delivers the point:

A X(A,B)(A a,B b){
    return a + b;
}

Obviously, the above is only useful for arithmetic types. Also, the return type of A is also just plucked out of the blue - we really can't assert what the *exact* return type is actually going to be and apply it to the template at the same time. So to ensure that it's used properly, the most succinct solution involves a variant type that is tolerant of it's own misuse:

// Var is our Variant struct
Var X(A,B)(A a,B b){
    return Var(a) + Var(b);
}

As a bonus, we can now return a result since we know exactly what type it is. Before, the return type could not be determined as based on the product of the operation, or without passing some return type to the template.

The overall concept here (as I see it) is to take all the common static if() type deduction code and template overloads typically applied to templates that require primitive types, and roll them into one runtime Variant type.

With the last set of compile-time features in D, there is little point to having much of tango.util.meta any more. Traits will be moved back into core and tango.util.meta will be removed from the lib.

Changes applied in [1873].

I'm closing this issue. Variants should be submitted as a separate enhancement request and will be evaluated later.