www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 6365] New: AutoTupleDeclaration

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6365

           Summary: AutoTupleDeclaration
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: k.hara.pg gmail.com



Syntax:
'auto' '(' Identifier [',' Identifier ...] ')' '=' Initializer ';'

Example:
auto (num, msg) = TypeTuple!(1, "hello");  // built-in tuple
assert(num == 1);
assert(msg == "hello");

auto (name, age) = tuple("John", 10);  // library tuple (= alias this tuple)
assert(name == "John");
assert(age == 10);

auto (n1, n2) = 100;  // non tuple initializer
assert(n1 == 100);
assert(n2 == 100);

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 23 2011
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6365




Also we can allow a static array on initializer like follows:

auto (x, y) = [10, 20];
assert(x == 10);
assert(y == 20);

But, it has a bit problem.

auto (x, y) = [10, 20, 30];  // interpreted as non tuple initializer
assert(x == [10, 20, 30]);
assert(y == [10, 20, 30]);

auto (x, y) = [10];  // interpreted as non tuple initializer
assert(x == [10]);
assert(y == [10]);

It is not inconsistent, but less useful.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 23 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6365


bearophile_hugs eml.cc changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bearophile_hugs eml.cc






 auto (n1, n2) = 100;  // non tuple initializer
 assert(n1 == 100);
 assert(n2 == 100);


This *must* be a compile-time error.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 23 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6365







 

 auto (n1, n2) = 100;  // non tuple initializer
 assert(n1 == 100);
 assert(n2 == 100);


 
 This *must* be a compile-time error.


This is keeping consistent feature.
Current D allow compilation of following code:

TypeTuple!(int, int) f = 10;
assert(f[0] == 10);
assert(f[1] == 10);

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 23 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6365




Optionally there is the foreach use case too. A possible syntax:

auto array = [tuple(1,"foo"), tuple(2,"bar")];
foreach (tuple(id, name); array) {}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 23 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6365







 This is keeping consistent feature.
 Current D allow compilation of following code:
 
 TypeTuple!(int, int) f = 10;
 assert(f[0] == 10);
 assert(f[1] == 10);


I didn't know this, thank you. So the semantics of TypeTuple is broken. This
design mistake must not be carried over to Tuples too. Consistancy with a so
wrong design is like shooting yourself in the foot and makes this whole
enhancement request of negative value.

It's better to fix this TypeTuple design bug instead. I will file an
enhancement request on it.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 23 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6365






 Optionally there is the foreach use case too. A possible syntax:
 
 auto array = [tuple(1,"foo"), tuple(2,"bar")];
 foreach (tuple(id, name); array) {}


I filed an issue about alias this + foreach range.front behavior.
http://d.puremagic.com/issues/show_bug.cgi?id=6366
Please comment there.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 23 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6365


Andrei Alexandrescu <andrei metalanguage.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andrei metalanguage.com



07:32:23 PDT ---
One simple syntactic matter is that we can't extend the existing syntax to work
with specified types. That means the user must use "auto" but cannot specify
the types of the variables defined.

To allow that in the future, we need to move the paren before the auto:

(auto i, j) = tuple(1.2, "a");

Then the syntax can be later extended to:

(double i, string j) = tuple(1.2, "a");

Anyway, we should wait for Walter to weigh in. Thanks Kenji for this work.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 23 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6365




07:33:33 PDT ---
Regarding mismatch in the number of elements, we may actually do good to
disable

TypeTuple!(int, int) f = 10;
assert(f[0] == 10);
assert(f[1] == 10);

instead of striving to be consistent with it.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 23 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6365






 Regarding mismatch in the number of elements, we may actually do good to
 disable
 
 TypeTuple!(int, int) f = 10;
 assert(f[0] == 10);
 assert(f[1] == 10);
 
 instead of striving to be consistent with it.


This was right my point. On this I have opened bug 6367

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 23 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6365




---


 One simple syntactic matter is that we can't extend the existing syntax to work
 with specified types. That means the user must use "auto" but cannot specify
 the types of the variables defined.
 
 To allow that in the future, we need to move the paren before the auto:
 
 (auto i, j) = tuple(1.2, "a");
 
 Then the syntax can be later extended to:
 
 (double i, string j) = tuple(1.2, "a");
 
 Anyway, we should wait for Walter to weigh in. Thanks Kenji for this work.


How about this syntax?
auto (i, j) = tuple(1.2, "a");
(double, string) (i, j) = tuple(1.2, "a");

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 23 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6365




---
Oops, I forgot to paste experimental patch link.
https://github.com/9rnsr/dmd/compare/expandTuples...declarationTuple

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 23 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6365








 (auto i, j) = tuple(1.2, "a");
 
 Then the syntax can be later extended to:
 
 (double i, string j) = tuple(1.2, "a");
 
 Anyway, we should wait for Walter to weigh in. Thanks Kenji for this work.


 
 How about this syntax?
 auto (i, j) = tuple(1.2, "a");
 (double, string) (i, j) = tuple(1.2, "a");


It's not ugly, but I think this looks a bit better:
(double i, string j) = tuple(1.2, "a");

Also because it's closer to (more consistent with) the currently used
definition syntax:
alias Tuple!(double,"i", string,"j") T1;
auto t1 = T1(1.2, "a");

If eventually the definition syntax too will become built-in, then you will
have something like:
alias (double i, string j) T2;
auto t2 = T2(1.2, "a");

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 23 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6365




Tuple slicing and other situations create tuples with 1 items or 0 items:

auto t = tuple(1.5, "foo");
auto t1 = t[0 .. 1];
auto t2 = t[0 .. 0];

In python they are written:
(x,)  or x,
()

For the 1-tuple D may do use the same syntax (but here parentheses are
requires, while in Python they are optional):
auto (x,) = [10];
auto (y,) = t1;

What about 0-length tuples?
int[0] a;
() = a;
() = t2;

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 23 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6365




See also the idea of switching on tuples, in issue 596

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 23 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6365




---
I found a conflict like follows:
  (double, string) (i, j) = tuple(1.2, "a");
  (var, func)(var, var) = tuple(1.2, "a");
So it is bad.


I clean up syntax, and update patch.
https://github.com/9rnsr/dmd/compare/expandTuples...declarationTuple

----
TupleDeclaration:
    StorageClasses ( IdentifierList ) = Initializer ;   // 1
    ( ParameterList ) = Initializer ;                   // 2-1
    ( StorageClass TupleTypeList ) = Initializer ;      // 2-2

TupleTypeList:
    TupleType
    TupleType , TupleTypeList

TupleType:
    StorageClasses BasicType Declarator
    BasicType Declarator
    StorageClasses Identifier
    Identifier

----
// Example of 1
    auto (i, j) = tuple(10, "a");
    static assert(is(typeof(i) == int));
    static assert(is(typeof(j) == string));

    const (x, y) = TypeTuple!(1, 2);
    static assert(is(typeof(x) == const(int)));
    static assert(is(typeof(y) == const(int)));

// Example of 2-1
    (int i, string j) = tuple(10, "a");
    static assert(is(typeof(i) == int));
    static assert(is(typeof(j) == string));

// Example of 2-2
    (auto c, r) = TypeTuple!('c', "har");
    static assert(is(typeof(c) == char));
    static assert(is(typeof(r) == string));

    (const x, auto y) = TypeTuple!(1, 2);
    static assert(is(typeof(x) == const(int)));
    static assert(is(typeof(y) == int));

    (auto a1, const int[] a2) = TypeTuple!([1], [2,3]);
    static assert(is(typeof(a1) == int[]));
    static assert(is(typeof(a2) == const(int[])));
----

TupleTypeList is similar to ForeachTypeList.
http://d-programming-language.org/statement.html#ForeachStatement

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 24 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6365







 I clean up syntax, and update patch.
 https://github.com/9rnsr/dmd/compare/expandTuples...declarationTuple


Thank you.

How does it behave for:
a[1] = [10];
auto (x, y) = a;

How does it behave for 0-tuples and 1-tuples?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 24 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6365




---


 How does it behave for 0-tuples and 1-tuples?


I think 1-element tuple expansion should be allowed.
Now my patch's this support is incomplete. I'll improve it.

// 1-tuple expansion
auto (x1) = [10];
(auto x2) = tuple(10);
(auto x3) = tuple(10)[0..1];
(int x4) = TypeTuple!(10);
assert(x1 == 10);
assert(x2 == 10);
assert(x3 == 10);
assert(x4 == 10);


The 0-element tuple with TupleDeclaration should be error.
Because they has no elements, so expansion cannot get value.

//auto () = [];
//(auto ) = tuple();

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 24 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6365






 
 // 1-tuple expansion
 auto (x1) = [10];


Are you sure you want to use that syntax?

A syntax more similar to the Python one is:

auto (x1,) = [10];

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 24 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6365




---


 Are you sure you want to use that syntax?


Yes. The syntax is usuful for tuple expansion and non-auto binding:
const (x, y) = tuple(10, 20);
// x and y are now const

It is more usuful for many element tuple:
(const x, const y, const z, const v, const w, const m, const n) = ... ;
// same as:
// const (x, y, z, v, w, m, n) = ... ;


 A syntax more similar to the Python one is:
 
 auto (x1,) = [10];


In D, Isolated comma is almost invalid except enum declaration, I think.
D is not Python.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 24 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6365






 In D, Isolated comma is almost invalid except enum declaration, I think.


This too is valid D code:

auto a = [1, 2,];

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 24 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6365




---


 This too is valid D code:
 
 auto a = [1, 2,];


I didn't know that. Thank you.

<cut>
In this case, TupleDeclaration syntax is similar to ParameterList.

void f(int i, string j){ ... }
(int i, string j) = tuple(1, "a");
auto (i, j) = tuple(1, "a");

But, 1 parameter function does not allow isolated comma.

void f(int i){ ... }
(int i) = tuple(1);
auto (i) = tuple(1);

//void f(int i,){ ... }  // invalid
//(int i,) = tuple(1);   // associatively invalid
//auto (i,) = tuple(1);  // associatively invalid

How about you?
</cut>

I didn't know following syntax is valid...

void f(int i, ){  }
(int i,) = tuple(1, "a");  // associatively valid
auto (i,) = tuple(1, "a"); // associatively valid

Hmm, it is hard achnowledgment to me, but it is valid syntax for consistency...

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 24 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6365




Two quite useful use cases:

A)
int[] array = [1, 2]; // dynamic array
auto (x, y) = array; // raises a run-time exception if array.length != 2


B)
auto (x, y, z) = iota(3); // raises a run-time exception if the lazy Range
doesn't yield exactly 3 itens.


Is it possible to support them too?


Regarding those run-time errors for those assignments, they are already present
in the language:

int[] array = [1, 2, 3];
int[2] a2 = array[];

object.Exception src\rt\arraycat.d(31): lengths don't match for array copy

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 25 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6365




21:03:44 PDT ---


 Two quite useful use cases:
 
 A)
 int[] array = [1, 2]; // dynamic array
 auto (x, y) = array; // raises a run-time exception if array.length != 2


No please. Too much magic for the benefit.


 B)
 auto (x, y, z) = iota(3); // raises a run-time exception if the lazy Range
 doesn't yield exactly 3 itens.


No please.

I'd say let's not go overboard. auto (names) = initializer; sounds like the
good thing to do, so let's do it. The rest are considerably more tenuous.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 25 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6365




---


 Also we can allow a static array on initializer like follows:
 
 auto (x, y) = [10, 20];
 assert(x == 10);
 assert(y == 20);


A few days ago, I wrote as above, but I think this is not good now.

Static arrays and array literals are certainly looks like a tuple, but in fact
they are not a tuple.
I think it is incorrect that dealing with them as tuples in TupleDeclaration.

I'll remove the feature from the experimental patch.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 26 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6365







 I'd say let's not go overboard. auto (names) = initializer; sounds like the
 good thing to do, so let's do it. The rest are considerably more tenuous.


They are common cases, I have opened issue 6383 about this.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 26 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6365


Walter Bright <bugzilla digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugzilla digitalmars.com



01:33:48 PDT ---
My main reservation about this is not that I can see anything obviously wrong
about it, but 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.

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 can give examples in other languages that did this - the most infamous being
the great C idea of conflating arrays and pointers. It seems to be a great idea
in the small, but only much larger experience showed what a disastrous mistake
it was.

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

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 02 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6365




---

Thanks for your reply.

I have two claims.

1. D language specification already implicitly allow automatic tuple expansion.

  a) Alias ​​this allows an implicit conversion to aliased symbol.
  b) We can take tuple symbol (= TupleDeclaration) as aliased symbol.

  The above two items lead automatic expansion naturally.
  If you prohibit that, it will make a serious exception to the language
specification.
  Dealing with the tuple expansion by alias this may complicate the
implementation of the compiler, but will not introduce an exception of language
specification.


2. Tuples are anonymous structures, and itself has no meaning.

  We should treat tuples as open, not closed.

　void f1(Point p); // struct Point{ int x, y; }
　void f2(int n, int m);

  The parameters of f1 and f2 are fundamentally different. And where
Tuple!(int, int) belongs to? I think it is same as parameters of f2.
  Therefore we need automatically expansion.

It seems to me that Tuple is essential feature to a modern language (like a
Unix pipe) .
And I believe that D is one of the very few languages that can treat it with
type-safe.

I did mark issues - 2779, 2781, 6366, 6369 as *BUG*.
Please think seriously about tuple expansion and alias this.

Sorry to my poor English.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 02 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6365




See also the discussion here:
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=141640

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 03 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6365







 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.


OK. Do you have hints on what kind of things we have to work on to solve this
problem?



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


Here I have done my best in stepping back:

http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=141640

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 08 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6365







 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: -------
Aug 18 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6365




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: -------
Aug 18 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6365




See also issue 6544

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 22 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6365


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

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



---
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: -------
Aug 27 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6365


dawg dawgfoto.de changed:

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



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: -------
Sep 08 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6365






 (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: -------
Sep 08 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6365




---
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: -------
Oct 20 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6365




---


 We should really strive to get a consistent syntax for this.
 auto (x, y) is a totally specialized syntax.



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: -------
Oct 20 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6365




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: -------
Nov 18 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6365




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: -------
Nov 18 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6365




Some people agree with me that mass assignment syntax for tuples is bad, it's
an anti-feature:

auto (i, j) = 10;
assert(i == 10);
assert(j == 10);


Like Alex R. Petersen:
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=151709

And Simen Kjaras:
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=151709

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Dec 14 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6365


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

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|AutoTupleDeclaration        |Multiple var declaration



---
Changed title from "AutoTupleDeclaration" to "Multiple var declaration".
(The name "TupleDeclaration" is already exist in dmd compiler source)

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 23 2012
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6365


Andrej Mitrovic <andrej.mitrovich gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |wbaxter gmail.com



11:31:49 PST ---
*** Issue 538 has been marked as a duplicate of this issue. ***

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