bearophile_hugs@eml.cc 
| http://d.puremagic.com/issues/show_bug.cgi?id=6544
Summary: Tuple unpacking at the called function
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nobody@puremagic.com
ReportedBy: bearophile_hugs@eml.cc
--- Comment #0 from bearophile_hugs@eml.cc 2011-08-22 23:51:42 PDT ---
As bug 6383 (Unpacking from dynamic array, lazy ranges) this is another spinoff
of Issue 6365 (AutoTupleDeclaration).
Functional languages as OCaML and Haskell show another quite useful way to use tuples.
This OCaML function returns the sum of two RGB colors (here represented with a 3-tuple of FP values), this is typical code:
let rgb_add (r1,g1,b1) (r2,g2,b2) =
(r1 +. r2,
g1 +. g2,
b1 +. b2)
Often the fields of a tuple don't have a name. So in D currently you have to write it in a quite more noisy way:
auto rgbAdd(Color c1, Color c2) {
return Color(c1[0] + c2[0], c1[1] + c2[1], c1[2] + c2[2]);
}
When AutoTupleDeclaration is accepted, you are also allowed to write:
auto rgbAdd(Color c1, Color c2) {
auto (r1,g1,b1) = c1;
auto (r2,g2,b2) = c2;
return Color(r1 + r2, g1 + g2, b1 + b2);
}
If the fields of Color have a name the situation improves a bit:
auto rgbAdd(Color c1, Col c2) {
return Color(c1.r + c2.r, c1.g + c2.g, c1.b + c2.b);
}
With a syntax to unpack tuples at the function arguments the code improves some more (this is just a made up syntax, it's just an example):
auto rgbAdd(Color(r1,g1,b1), Color(r2,g2,b2)) {
return Color(r1 + r2, g1 + g2, b1 + b2);
}
Sometimes you have an anonymous tuple type, and "don't care" arguments. Currently this doesn't work also because "_" is a valid variable name, so you can't use it more than once (again, this is made up syntax used to explain):
bool greenCompare(Tuple!(_, float g1, _), Tuple!(_, float g2, _)) {
return g1 > g2;
}
Currently in D there is a bit of support for tuple expansion:
auto rgbAdd(float r1, float g1, float b1, float r2, float g2, float b2) {
return Color(r1 + r2, g1 + g2, b1 + b2);
}
...
rgbAdd(c1.tupleof, c2.tupleof);
But this forces the call point to use .tupleof. This is sometimes acceptable (even if less nice), but in other cases you can't use it. Here filter doesn't use .tupleof, so this code has arity bugs:
bool greenCompare2(float r1, float g1, float b1, float r2, float g2, float b2)
{
return g1 > g2;
}
auto r = filter!greenCompare2([Color(1,2,3), Color(4,5,6)]);
In general the unpacking of tuples at the function signature gives more flexibility. Functional languages often use such flexibility.
Python2 has the feature discussed in this enhancement request, Python3 has removed this feature to simplify the language implementation. But functional languages use this feature all the time, sometimes in almost every function signature.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
|
Permalink
Reply