Download Reference Manual
The Developer's Library for D
About Wiki Forums Source Search Contact

Ticket #132 (closed task: fixed)

Opened 14 years ago

Last modified 14 years ago

Tango template/meta world

Reported by: larsivi Assigned to: sean
Priority: major Milestone: 0.96 Beta 2
Component: Tango Version:
Keywords: Cc:

Description

We want Tango to stay on top of the templating possibilities in D, and thus we need to make sure that

  • Phobos template functionality (std.boxer, std.traits, std.typetuple) is at least reflected, preferably superceded in Tango
  • That we a reasonable set of meta modules/functionality (for instance bind/tuples/currying)
  • If containers can make good use of recent template additions to make them easier to use, more powerful, and more efficient, then we should strive to make them so.

Sean, Tom, Don and Kirk are likely contributors/supervisors

Change History

11/15/06 19:44:18 changed by larsivi

  • type changed from defect to task.

12/16/06 15:29:16 changed by larsivi

  • milestone changed from 0.9 to 0.95 Beta1.

12/26/06 21:16:30 changed by sean

* 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.

01/09/07 10:25:20 changed by larsivi

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?

01/10/07 01:00:34 changed by kris

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

02/03/07 15:09:13 changed by larsivi

  • milestone changed from 0.95 Beta1 to 0.96 Beta 2.

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

02/15/07 07:27:46 changed by sean

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.

02/15/07 09:22:03 changed by larsivi

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

02/16/07 20:09:09 changed by pragma

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.

03/10/07 18:20:18 changed by sean

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.

03/10/07 18:25:19 changed by sean

Changes applied in [1873].

03/14/07 17:53:46 changed by sean

  • status changed from new to closed.
  • resolution set to fixed.

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