[Issue 6365] AutoTupleDeclaration
http://d.puremagic.com/issues/show_bug.cgi?id=6365
--- Comment #38 from bearophile_h...@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: ---
[Issue 6365] AutoTupleDeclaration
http://d.puremagic.com/issues/show_bug.cgi?id=6365 --- Comment #39 from bearophile_h...@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: ---
[Issue 6365] AutoTupleDeclaration
http://d.puremagic.com/issues/show_bug.cgi?id=6365 --- Comment #36 from Kenji Hara k.hara...@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: ---
[Issue 6365] AutoTupleDeclaration
http://d.puremagic.com/issues/show_bug.cgi?id=6365 --- Comment #37 from Kenji Hara k.hara...@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: ---
[Issue 6365] AutoTupleDeclaration
http://d.puremagic.com/issues/show_bug.cgi?id=6365 d...@dawgfoto.de changed: What|Removed |Added CC||d...@dawgfoto.de --- Comment #34 from d...@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: ---
[Issue 6365] AutoTupleDeclaration
http://d.puremagic.com/issues/show_bug.cgi?id=6365 --- Comment #35 from d...@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: ---
[Issue 6365] AutoTupleDeclaration
http://d.puremagic.com/issues/show_bug.cgi?id=6365 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||patch --- Comment #33 from Kenji Hara k.hara...@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: ---
[Issue 6365] AutoTupleDeclaration
http://d.puremagic.com/issues/show_bug.cgi?id=6365 --- Comment #32 from bearophile_h...@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: ---
[Issue 6365] AutoTupleDeclaration
http://d.puremagic.com/issues/show_bug.cgi?id=6365 --- Comment #30 from bearophile_h...@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: ---
[Issue 6365] AutoTupleDeclaration
http://d.puremagic.com/issues/show_bug.cgi?id=6365
--- Comment #31 from bearophile_h...@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: ---
[Issue 6365] AutoTupleDeclaration
http://d.puremagic.com/issues/show_bug.cgi?id=6365 --- Comment #29 from bearophile_h...@eml.cc 2011-08-08 14:48:37 PDT --- (In reply to comment #26) 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.Darticle_id=141640 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6365] AutoTupleDeclaration
http://d.puremagic.com/issues/show_bug.cgi?id=6365 --- Comment #28 from bearophile_h...@eml.cc 2011-08-03 04:35:25 PDT --- See also the discussion here: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.Darticle_id=141640 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6365] AutoTupleDeclaration
http://d.puremagic.com/issues/show_bug.cgi?id=6365 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #26 from Walter Bright bugzi...@digitalmars.com 2011-08-02 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: ---
[Issue 6365] AutoTupleDeclaration
http://d.puremagic.com/issues/show_bug.cgi?id=6365
--- Comment #27 from Kenji Hara k.hara...@gmail.com 2011-08-02 06:39:43 PDT
---
(In reply to comment #26)
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: ---
[Issue 6365] AutoTupleDeclaration
http://d.puremagic.com/issues/show_bug.cgi?id=6365 --- Comment #24 from Kenji Hara k.hara...@gmail.com 2011-07-26 02:45:09 PDT --- (In reply to comment #1) 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: ---
[Issue 6365] AutoTupleDeclaration
http://d.puremagic.com/issues/show_bug.cgi?id=6365 --- Comment #22 from bearophile_h...@eml.cc 2011-07-25 19:56:30 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 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: ---
[Issue 6365] AutoTupleDeclaration
http://d.puremagic.com/issues/show_bug.cgi?id=6365 --- Comment #23 from Andrei Alexandrescu and...@metalanguage.com 2011-07-25 21:03:44 PDT --- (In reply to comment #22) 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: ---
[Issue 6365] AutoTupleDeclaration
http://d.puremagic.com/issues/show_bug.cgi?id=6365
--- Comment #15 from Kenji Hara k.hara...@gmail.com 2011-07-24 06:41:36 PDT
---
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: ---
[Issue 6365] AutoTupleDeclaration
http://d.puremagic.com/issues/show_bug.cgi?id=6365 --- Comment #16 from bearophile_h...@eml.cc 2011-07-24 07:24:53 PDT --- (In reply to comment #15) 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: ---
[Issue 6365] AutoTupleDeclaration
http://d.puremagic.com/issues/show_bug.cgi?id=6365 --- Comment #17 from Kenji Hara k.hara...@gmail.com 2011-07-24 07:38:49 PDT --- (In reply to comment #16) 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: ---
[Issue 6365] AutoTupleDeclaration
http://d.puremagic.com/issues/show_bug.cgi?id=6365 --- Comment #18 from bearophile_h...@eml.cc 2011-07-24 11:14:57 PDT --- (In reply to comment #17) // 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: ---
[Issue 6365] AutoTupleDeclaration
http://d.puremagic.com/issues/show_bug.cgi?id=6365
--- Comment #21 from Kenji Hara k.hara...@gmail.com 2011-07-24 12:20:00 PDT
---
(In reply to comment #20)
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: ---
[Issue 6365] AutoTupleDeclaration
http://d.puremagic.com/issues/show_bug.cgi?id=6365 --- Comment #1 from Kenji Hara k.hara...@gmail.com 2011-07-23 05:08:51 PDT --- 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: ---
[Issue 6365] AutoTupleDeclaration
http://d.puremagic.com/issues/show_bug.cgi?id=6365 bearophile_h...@eml.cc changed: What|Removed |Added CC||bearophile_h...@eml.cc --- Comment #2 from bearophile_h...@eml.cc 2011-07-23 05:14:44 PDT --- (In reply to comment #0) 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: ---
[Issue 6365] AutoTupleDeclaration
http://d.puremagic.com/issues/show_bug.cgi?id=6365 --- Comment #3 from Kenji Hara k.hara...@gmail.com 2011-07-23 05:17:57 PDT --- (In reply to comment #2) (In reply to comment #0) 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: ---
[Issue 6365] AutoTupleDeclaration
http://d.puremagic.com/issues/show_bug.cgi?id=6365
--- Comment #4 from bearophile_h...@eml.cc 2011-07-23 05:18:55 PDT ---
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: ---
[Issue 6365] AutoTupleDeclaration
http://d.puremagic.com/issues/show_bug.cgi?id=6365 --- Comment #5 from bearophile_h...@eml.cc 2011-07-23 05:23:06 PDT --- (In reply to comment #3) 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: ---
[Issue 6365] AutoTupleDeclaration
http://d.puremagic.com/issues/show_bug.cgi?id=6365
--- Comment #6 from Kenji Hara k.hara...@gmail.com 2011-07-23 05:27:14 PDT ---
(In reply to comment #4)
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: ---
[Issue 6365] AutoTupleDeclaration
http://d.puremagic.com/issues/show_bug.cgi?id=6365 --- Comment #8 from Andrei Alexandrescu and...@metalanguage.com 2011-07-23 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: ---
[Issue 6365] AutoTupleDeclaration
http://d.puremagic.com/issues/show_bug.cgi?id=6365 Andrei Alexandrescu and...@metalanguage.com changed: What|Removed |Added CC||and...@metalanguage.com --- Comment #7 from Andrei Alexandrescu and...@metalanguage.com 2011-07-23 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: ---
[Issue 6365] AutoTupleDeclaration
http://d.puremagic.com/issues/show_bug.cgi?id=6365 --- Comment #9 from bearophile_h...@eml.cc 2011-07-23 07:48:46 PDT --- (In reply to comment #8) 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: ---
[Issue 6365] AutoTupleDeclaration
http://d.puremagic.com/issues/show_bug.cgi?id=6365 --- Comment #10 from Kenji Hara k.hara...@gmail.com 2011-07-23 08:28:08 PDT --- (In reply to comment #7) 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: ---
[Issue 6365] AutoTupleDeclaration
http://d.puremagic.com/issues/show_bug.cgi?id=6365 --- Comment #11 from Kenji Hara k.hara...@gmail.com 2011-07-23 08:33:10 PDT --- 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: ---
[Issue 6365] AutoTupleDeclaration
http://d.puremagic.com/issues/show_bug.cgi?id=6365 --- Comment #12 from bearophile_h...@eml.cc 2011-07-23 09:03:24 PDT --- (In reply to comment #10) (In reply to comment #7) (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: ---
[Issue 6365] AutoTupleDeclaration
http://d.puremagic.com/issues/show_bug.cgi?id=6365 --- Comment #13 from bearophile_h...@eml.cc 2011-07-23 12:04:19 PDT --- 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: ---
[Issue 6365] AutoTupleDeclaration
http://d.puremagic.com/issues/show_bug.cgi?id=6365 --- Comment #14 from bearophile_h...@eml.cc 2011-07-23 12:14:23 PDT --- 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: ---
