[Issue 6365] AutoTupleDeclaration

2011-12-14 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=6365



--- Comment #40 from bearophile_h...@eml.cc 2011-12-14 00:01:37 PST ---
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.Darticle_id=151709

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

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


[Issue 6365] AutoTupleDeclaration

2011-11-18 Thread d-bugmail
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

2011-11-18 Thread d-bugmail
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

2011-10-20 Thread d-bugmail
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

2011-10-20 Thread d-bugmail
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

2011-09-08 Thread d-bugmail
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

2011-09-08 Thread d-bugmail
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

2011-08-27 Thread d-bugmail
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

2011-08-23 Thread d-bugmail
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

2011-08-19 Thread d-bugmail
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

2011-08-19 Thread d-bugmail
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

2011-08-08 Thread d-bugmail
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

2011-08-03 Thread d-bugmail
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

2011-08-02 Thread d-bugmail
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

2011-08-02 Thread d-bugmail
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

2011-07-26 Thread d-bugmail
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

2011-07-26 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=6365



--- Comment #25 from bearophile_h...@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: ---


[Issue 6365] AutoTupleDeclaration

2011-07-25 Thread d-bugmail
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

2011-07-25 Thread d-bugmail
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

2011-07-24 Thread d-bugmail
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

2011-07-24 Thread d-bugmail
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

2011-07-24 Thread d-bugmail
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

2011-07-24 Thread d-bugmail
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

2011-07-24 Thread d-bugmail
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

2011-07-23 Thread d-bugmail
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

2011-07-23 Thread d-bugmail
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

2011-07-23 Thread d-bugmail
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

2011-07-23 Thread d-bugmail
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

2011-07-23 Thread d-bugmail
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

2011-07-23 Thread d-bugmail
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

2011-07-23 Thread d-bugmail
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

2011-07-23 Thread d-bugmail
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

2011-07-23 Thread d-bugmail
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

2011-07-23 Thread d-bugmail
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

2011-07-23 Thread d-bugmail
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

2011-07-23 Thread d-bugmail
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

2011-07-23 Thread d-bugmail
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

2011-07-23 Thread d-bugmail
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: ---