http://d.puremagic.com/issues/show_bug.cgi?id=6365



--- Comment #30 from bearophile_hugs@eml.cc 2011-08-18 23:35:27 PDT ---
(In reply to comment #26)

> We should step back and figure out what we want to do with tuples in the much more general case.

I think this point is mostly solved, because while tuples are useful for many different purposes and situations, such purposes are well known. Languages like Python, Haskell and Scala show and contain most significant usages for tuples.



> I am nervous we are building a special case for tuples. I think
> any expansion of tuple support should be part of a more comprehensive design
> for tuples.

I agree. This is why I have created issue 6383 . It deals with more general idea of unpacking. Issue 6383 doesn't cover all possible situations, but they are enough to start.


> If we grow tuple support by adding piecemeal special cases for this and that, without thinking about them more globally, we are liable to build ourselves into a box we can't get out of.

I have done my best. But the discussion has stopped.
So my suggestion is to put this in the next DMD release as *experimental*
feature, and let people:
1) Try it and find what's good and bad of it through practical experience, and
even trial and error;
2) Use this concrete implementation as a trampoline to think in abstract about
that good and bad of this current design.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6365



--- Comment #31 from bearophile_hugs@eml.cc 2011-08-18 23:47:46 PDT ---
Regarding this change, removing tuple unpacking for arrays is not a good idea, in my opinion. You are making tuples less handy, with zero gain in doing so.

https://github.com/9rnsr/dmd/commit/6fa008162fe29a1459c35dccb9e08009598206d0

Conceptually it's the same thing as doing:

void main() {
    int[] a = [1, 2];
    int[2] b = a;
}

The compiler will need to verify at runtime that a has length 2. Given this precedent in the language, there is no point in forbidding a similar operation on tuples:

void main() {
    int[] a1 = [1, 2];
    auto (x, y) = a1;
    int[2] a2 = [1, 2];
    auto (z, w) = a2; // no need to verify a2 length at runtime here
}


I think this is what Walter was talking about in comment 26:

>I think any expansion of tuple support should be part of a more comprehensive design for tuples.<


Python tuples support this operation, that feels natural enough to Python programmers:

>>> a1 = [1, 2]
>>> (x, y) = a1
>>> x
1
>>> y
2

So in my opinion Andrei is wrong here.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6365



--- Comment #32 from bearophile_hugs@eml.cc 2011-08-22 23:52:53 PDT ---
See also issue 6544

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6365


Kenji Hara <k.hara.pg@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |patch


--- Comment #33 from Kenji Hara <k.hara.pg@gmail.com> 2011-08-27 02:51:00 PDT ---
Posted pull request.

https://github.com/D-Programming-Language/dmd/pull/341

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6365


dawg@dawgfoto.de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dawg@dawgfoto.de


--- Comment #34 from dawg@dawgfoto.de 2011-09-08 10:06:09 PDT ---
We should really strive to get a consistent syntax for this.
auto (x, y) is a totally specialized syntax.
It seems to not extend to anything but declaration.
A useful tuple syntax must also be usable as expression at some day.

The whole tuple discussion is really a matter of deciding whether a tuple is
closed or open.
This is also the most confusing thing about the current tuples.

--- comma (open tuples)

auto a, b = tuple(2, 3);
auto head, match, tail = findSplit(str, "hello");
string head, match, auto tail = findSplit(str, "hello");
return a, b;
foo(int a, int b, string c) // default open
foo(int a, Tuple!(int, string) tup) // closed

 - don't require continuous memory layout (bundled aliases)
 - don't strictly have an identity
 - need enclosing holder a.k.a. typecons tuple
 - syntax should show they are not enclosed (auto (a, b) is misleading)
 - close to current implementation

The above syntax conflicts with 'int a, b = 2;' which never allowed to initialize both variables, but as much as I'm in favor of this, a semantic change towards this is a bit heavy. Also comma is a little overused.

--- embraced (closed tuple)

(auto a, b) = (2, 3);
(auto head, match, tail) = findSplit(string, "hello");
(string head, match, auto tail) = findSplit(string, "hello");
return (a, b);
foo(int a, (int, string) tup) // default closed
foo(int a, tup@(int a, string b)) // open through rebind

 - have continuous memory layout
 - do have a strict identity
 - need opening rebinding (e.g. tup@(a, b))
 - syntax should show they are closed (braces)
 - map to aggregates implementation-wise

Given that braces don't create ambiguities, brace enclosed tuples work well with expressions and give little surprise (Python, Haskell).

We will have to clarify the relationship of expression tuples and vararg templates. Tuples would become an own entity in the language.

P.S.:
Please be careful with such fundamental syntax decisions.
As a reminder 'import std.range, std.conv : to, parse, std.math : abs'.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6365



--- Comment #35 from dawg@dawgfoto.de 2011-09-08 10:15:17 PDT ---
(In reply to comment #34)
> (auto a, b) = (2, 3);
This would actually call for 'auto tup = (2, 3);' && '(auto a, b) tup = (2,
3);' || 'auto tup@(a, b) = (2, 3);'. So you can pass the tuple around without
creating a new one.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6365



--- Comment #36 from Kenji Hara <k.hara.pg@gmail.com> 2011-10-20 19:08:36 PDT ---
Scala has similar syntax.

http://www.scala-lang.org/docu/files/ScalaReference.pdf p.170
| Changes in Version 2.6.1 (30-Nov-2007)
| Mutable variables introduced by pattern binding
| Mutable variables can now be introduced by a pattern matching definition
(§4.2), | just like values can. Examples:
|     var (x, y) = if (positive) (1, 2) else (-1, -3)
|     var hd :: tl = mylist

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6365



--- Comment #37 from Kenji Hara <k.hara.pg@gmail.com> 2011-10-20 19:20:06 PDT ---
(In reply to comment #34)
> We should really strive to get a consistent syntax for this. auto (x, y) is a totally specialized syntax.

See comment #19. It is a special case of (auto x, auto y), and it is useful if you want to apply non-auto storage classes.

e.g.
const (x, y) -> (const x, const y)
const (int n, string s) -> (const int n, const string s)

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6365



--- Comment #38 from bearophile_hugs@eml.cc 2011-11-18 18:10:20 PST ---
See also bug 4579

------------------

Another handy sub-feature. Sometimes you have tuples with N items, but you only want to unpack some of them. This syntax doesn't work because "_" is a valid variable name (and even if there's only one of them I don't want to define a "_" variable):

auto t = tuple(1, 2.5, "hello", 'Z');
immutable (x1, void, s1, void) = t; // only x1 and s1 constants are created


Some "dontcare" syntax like that void is useful for issue 596 too:


import std.typecons: Tuple;
alias Tuple!(int, "x", int, "y") Foo;
void main() {
    auto f = Foo(1, 2);
    switch (f) {
        case Foo(1, void): break; // any Foo with x==1, don't care y
        default: break;
    }
}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6365



--- Comment #39 from bearophile_hugs@eml.cc 2011-11-18 18:11:33 PST ---
Please ignore the "This syntax doesn't work because "_" is a valid
variable name (and even if there's only one of them I don't want to define a
"_" variable):" part of the precedent comment.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------