On 09/24/2012 12:57 AM, Andrei Alexandrescu wrote:
On 9/23/12 6:42 PM, Timon Gehr wrote:
That is because it does not base the discussion on the right
limitations of built-in tuples:
Actually that is mostly unrelated to the comma operator. Apologies.
auto (a,b) = (1,"3");
(auto a, string b) = (1, "3");
I meant to mention that but forgot. The interesting thing about this is
that, if we decide it's the main issue with today's tuples, we pull
Kenji's patch and close the case.
Imho, it certainly is the main issue.
...
- We already use the name 'tuple'. I'd suggest renaming that to
'sequence' or similar. template Seq(T...){ alias T Seq; }
Then what are the "old" tuples?
Instances of TypeTuples, eg:
template Seq(T...){ alias T Seq; }
Seq!(int, double) foo(){ }
=> "Error: functions cannot return a tuple"
- The empty tuple can well be (), just like 'Seq!()' works without
issues (it is an expression that is also a type). What is wrong with
it?
There's already intensive use of parens in D. I predict there's going to
be big trouble with "()" even assuming it's not technical ambiguous,
Well, (,) cannot help with that.
for
example a lambda that returns an empty tuple would be "()() {...}" and
all that jazz.
Well, it would be ()=>() or delegate()()=>(), but is it even reasonable
to use the second form?
- How do we expand a sequence into a tuple?
=> (Seq!(1,2,3),)
I think we're discussing different things - the above seems to deal with
expression/alias tuples. DIP19 discusses strictly runtime value tuples.
I am discussing the interplay of the two features. Sequences are
auto-expanded in all contexts where it makes sense (except if they
happen to be the second argument to a comma expression, then they are
not, but I assume that is a bug.)
I expect the following to be equivalent:
(Seq!(1,2,3),)
and
(1,2,3)
- What is the calling convention used for passing built-in tuples to
and from functions?
I don't know. The current approach with .expand is nothing special - as
if the programmer wrote the expansion by hand.
Not sure we are on the same page. I meant the calling convention at the
ABI level.
- As tuples are built-in, expansion can be shorter than '.expand'.
foo(1, tup..., 3); ?
I find that sugar gratuitous.
You find built-in tuples gratuitous in general. :o)
Anyway, it certainly is not necessary.
- Template tuple parameters? This would work, but...
template Tuple((T...,)){ alias (T,) Tuple; }
void bar(T,(U...,),V...)(T delegate(U) dg, V args){ ... }
void foo(T,(U...,),(V...,))(T delegate(U) dg, V args){
bar!(T,Tuple!U,V)(dg, args);
} // U and V can be passed separately
- Named tuple fields?
(int x, int y) tuple = (1,2);
swap(tuple.x, tuple.y);
I kinda got lost around all that.
I assume named tuple fields are not a problem?
Other than that, I raised the issue of how to match and destructure
tuple types in template parameter lists. And came up with the following
proposal, which I do not like.
template Foo((U...,)){ alias (U,) Foo; }
void main(){
(int, double) x;
Foo!(typeof(x)) y;
static assert(is(typeof(x)==typeof(y)));
}
