Difference between revisions of "Instantiator Function Pattern"
(Created article) |
m |
||
Line 38: | Line 38: | ||
The instantiator function takes a variadic set of arguments and instantiates <code>Tuple</code> based on those arguments. In D, the return type can be introspected so the return type doesn't need to redundantly specified. In <code>main</code>, redundantly specifying argument types that the compiler already knows is avoided. | The instantiator function takes a variadic set of arguments and instantiates <code>Tuple</code> based on those arguments. In D, the return type can be introspected so the return type doesn't need to redundantly specified. In <code>main</code>, redundantly specifying argument types that the compiler already knows is avoided. | ||
+ | |||
+ | [[Category:DesignPattern]] |
Latest revision as of 10:18, 14 November 2014
From David Simcha's D-Specific Design Patterns talk at DConf 2013.
Problem: Instantiating class/struct templates
struct Tuple(Args...)
{
Args args_;
}
void main()
{
//Yuck!
auto myTuple = Tuple!(int, double, string)(1, 3.14, "foo");
}
The compiler already knows that 1
is an int
, 3.14
is a float
and "foo"
is a string
, yet this information is specified redundantly. To change one of the arguments, it must be changed in two different places.
Solution: Use Instantiator Function
struct Tuple(Args...)
{
Args args_;
}
// Instantiator function
Tuple!(Args) tuple(Args...)(Args args)
{
return typeof(return)(args);
}
void main()
{
// Much less verbose. Use IFTI.
auto myTuple = tuple(1, 3.14, "foo");
}
The instantiator function takes a variadic set of arguments and instantiates Tuple
based on those arguments. In D, the return type can be introspected so the return type doesn't need to redundantly specified. In main
, redundantly specifying argument types that the compiler already knows is avoided.