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: nob...@puremagic.com
        ReportedBy: bearophile_h...@eml.cc


--- Comment #0 from bearophile_h...@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: -------

Reply via email to