digitalmars.D.bugs - [Issue 6365] New: AutoTupleDeclaration
- d-bugmail puremagic.com (28/28) Jul 23 2011 http://d.puremagic.com/issues/show_bug.cgi?id=6365
- d-bugmail puremagic.com (17/17) Jul 23 2011 http://d.puremagic.com/issues/show_bug.cgi?id=6365
- d-bugmail puremagic.com (11/14) Jul 23 2011 http://d.puremagic.com/issues/show_bug.cgi?id=6365
- d-bugmail puremagic.com (11/18) Jul 23 2011 http://d.puremagic.com/issues/show_bug.cgi?id=6365
- d-bugmail puremagic.com (8/8) Jul 23 2011 http://d.puremagic.com/issues/show_bug.cgi?id=6365
- d-bugmail puremagic.com (12/18) Jul 23 2011 http://d.puremagic.com/issues/show_bug.cgi?id=6365
- d-bugmail puremagic.com (9/13) Jul 23 2011 http://d.puremagic.com/issues/show_bug.cgi?id=6365
- d-bugmail puremagic.com (17/17) Jul 23 2011 http://d.puremagic.com/issues/show_bug.cgi?id=6365
- d-bugmail puremagic.com (11/11) Jul 23 2011 http://d.puremagic.com/issues/show_bug.cgi?id=6365
- d-bugmail puremagic.com (7/15) Jul 23 2011 http://d.puremagic.com/issues/show_bug.cgi?id=6365
- d-bugmail puremagic.com (9/22) Jul 23 2011 http://d.puremagic.com/issues/show_bug.cgi?id=6365
- d-bugmail puremagic.com (7/7) Jul 23 2011 http://d.puremagic.com/issues/show_bug.cgi?id=6365
- d-bugmail puremagic.com (16/28) Jul 23 2011 http://d.puremagic.com/issues/show_bug.cgi?id=6365
- d-bugmail puremagic.com (20/20) Jul 23 2011 http://d.puremagic.com/issues/show_bug.cgi?id=6365
- d-bugmail puremagic.com (6/6) Jul 23 2011 http://d.puremagic.com/issues/show_bug.cgi?id=6365
- d-bugmail puremagic.com (49/49) Jul 24 2011 http://d.puremagic.com/issues/show_bug.cgi?id=6365
- d-bugmail puremagic.com (11/13) Jul 24 2011 http://d.puremagic.com/issues/show_bug.cgi?id=6365
- d-bugmail puremagic.com (21/22) Jul 24 2011 http://d.puremagic.com/issues/show_bug.cgi?id=6365
- d-bugmail puremagic.com (9/12) Jul 24 2011 http://d.puremagic.com/issues/show_bug.cgi?id=6365
- d-bugmail puremagic.com (15/19) Jul 24 2011 http://d.puremagic.com/issues/show_bug.cgi?id=6365
- d-bugmail puremagic.com (8/9) Jul 24 2011 http://d.puremagic.com/issues/show_bug.cgi?id=6365
- d-bugmail puremagic.com (26/29) Jul 24 2011 http://d.puremagic.com/issues/show_bug.cgi?id=6365
- d-bugmail puremagic.com (18/18) Jul 25 2011 http://d.puremagic.com/issues/show_bug.cgi?id=6365
- d-bugmail puremagic.com (10/18) Jul 25 2011 http://d.puremagic.com/issues/show_bug.cgi?id=6365
- d-bugmail puremagic.com (11/16) Jul 26 2011 http://d.puremagic.com/issues/show_bug.cgi?id=6365
- d-bugmail puremagic.com (7/9) Jul 26 2011 http://d.puremagic.com/issues/show_bug.cgi?id=6365
- d-bugmail puremagic.com (22/22) Aug 02 2011 http://d.puremagic.com/issues/show_bug.cgi?id=6365
- d-bugmail puremagic.com (31/31) Aug 02 2011 http://d.puremagic.com/issues/show_bug.cgi?id=6365
- d-bugmail puremagic.com (7/7) Aug 03 2011 http://d.puremagic.com/issues/show_bug.cgi?id=6365
- d-bugmail puremagic.com (10/15) Aug 08 2011 http://d.puremagic.com/issues/show_bug.cgi?id=6365
- d-bugmail puremagic.com (19/27) Aug 18 2011 http://d.puremagic.com/issues/show_bug.cgi?id=6365
- d-bugmail puremagic.com (28/33) Aug 18 2011 http://d.puremagic.com/issues/show_bug.cgi?id=6365
- d-bugmail puremagic.com (6/6) Aug 22 2011 http://d.puremagic.com/issues/show_bug.cgi?id=6365
- d-bugmail puremagic.com (11/11) Aug 27 2011 http://d.puremagic.com/issues/show_bug.cgi?id=6365
- d-bugmail puremagic.com (50/50) Sep 08 2011 http://d.puremagic.com/issues/show_bug.cgi?id=6365
- d-bugmail puremagic.com (9/10) Sep 08 2011 http://d.puremagic.com/issues/show_bug.cgi?id=6365
- d-bugmail puremagic.com (13/13) Oct 20 2011 http://d.puremagic.com/issues/show_bug.cgi?id=6365
- d-bugmail puremagic.com (11/13) Oct 20 2011 http://d.puremagic.com/issues/show_bug.cgi?id=6365
- d-bugmail puremagic.com (23/23) Nov 18 2011 http://d.puremagic.com/issues/show_bug.cgi?id=6365
- d-bugmail puremagic.com (8/8) Nov 18 2011 http://d.puremagic.com/issues/show_bug.cgi?id=6365
- d-bugmail puremagic.com (14/14) Dec 14 2011 http://d.puremagic.com/issues/show_bug.cgi?id=6365
- d-bugmail puremagic.com (11/11) Jan 23 2012 http://d.puremagic.com/issues/show_bug.cgi?id=6365
- d-bugmail puremagic.com (10/10) Jan 20 2013 http://d.puremagic.com/issues/show_bug.cgi?id=6365
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
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
http://d.puremagic.com/issues/show_bug.cgi?id=6365 bearophile_hugs eml.cc changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bearophile_hugs eml.ccauto (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
http://d.puremagic.com/issues/show_bug.cgi?id=6365This 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: -------auto (n1, n2) = 100; // non tuple initializer assert(n1 == 100); assert(n2 == 100);This *must* be a compile-time error.
Jul 23 2011
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
http://d.puremagic.com/issues/show_bug.cgi?id=6365This 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
http://d.puremagic.com/issues/show_bug.cgi?id=6365Optionally 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
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
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
http://d.puremagic.com/issues/show_bug.cgi?id=6365Regarding 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
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
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
http://d.puremagic.com/issues/show_bug.cgi?id=6365It'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: -------(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");
Jul 23 2011
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
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
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
http://d.puremagic.com/issues/show_bug.cgi?id=6365I clean up syntax, and update patch. https://github.com/9rnsr/dmd/compare/expandTuples...declarationTupleThank 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
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
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
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
http://d.puremagic.com/issues/show_bug.cgi?id=6365In 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
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
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
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 != 2No 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
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
http://d.puremagic.com/issues/show_bug.cgi?id=6365I'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
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
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
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
http://d.puremagic.com/issues/show_bug.cgi?id=6365If 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
http://d.puremagic.com/issues/show_bug.cgi?id=6365We 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
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:1a1 = [1, 2] (x, y) = a1 x2 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: -------y
Aug 18 2011
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
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
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
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
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
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
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
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
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
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
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