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



--- Comment #20 from bearophile_hugs@eml.cc 2011-07-24 12:01:55 PDT ---
(In reply to comment #19)
> 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: -------

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



--- Comment #21 from Kenji Hara <k.hara.pg@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: -------

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



--- Comment #22 from bearophile_hugs@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: -------

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



--- Comment #23 from Andrei Alexandrescu <andrei@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: -------

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



--- Comment #24 from Kenji Hara <k.hara.pg@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: -------

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



--- Comment #25 from bearophile_hugs@eml.cc 2011-07-26 06:53:52 PDT ---
(In reply to comment #23)

> 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: -------

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


Walter Bright <bugzilla@digitalmars.com> changed:

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


--- Comment #26 from Walter Bright <bugzilla@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: -------

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



--- Comment #27 from Kenji Hara <k.hara.pg@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: -------

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



--- Comment #28 from bearophile_hugs@eml.cc 2011-08-03 04:35:25 PDT ---
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: -------

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



--- Comment #29 from bearophile_hugs@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.D&article_id=141640

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