On Sunday, 23 September 2012 at 22:55:33 UTC, Timon Gehr wrote:
> I believe it is currently left-to-right for D, in all kinds of
> expressions, but DMD does not implement it yet.

Yeah, I thought it was already defined.

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)));
}

On 09/24/2012 01:08 AM, deadalnix wrote:
> Le 24/09/2012 00:48, Andrei Alexandrescu a écrit :
>> This notion a lot of trouble with it; I think it's safe to abandon it
>> entirely.
>>
>> Once a one-element tuple becomes equivalent to the actual item, there's
>> an explosion of trouble and special cases in the language and in code
>> that uses it. For example, divide and conquer code that manipulates
>> tuples and takes t[0 .. $/2] and t[$/2+1 .. $] would suddenly get to
>> cases in which the slices are no longer tuples, and so on. And that's
>> only the beginning.
>>
>
> This is a very weak point. In most cases, divide an conquer with tuple
> don't even make sense.
>
>> Also, having no integrated notion of a zero-element tuple would again
>> mess with the algebra as much as the absence of 0 would hurt numbers.
>> It's just troublesome.
>>
>> I appreciate the attraction of this idea, but again I think it's safe to
>> just not even discuss it.
>>
>
> I'm not sure I want to answer that, so I wont.

I agree with Andrei. Single element tuples need to support the same
operations as tuples of other arities do.

Andrei Alexandrescu:

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

As I have tried to explain in my precedent post, Kenji's patch covers about 1/4 of the most important use cases.

Bye,
bearophile

Timon Gehr:

> cases already introduce their own scopes in D,

Thank you, I didn't remember this.


> but switch cannot be extended well to serve such use cases.

Please explain, as I am not able to see the problems.

I have discussed that topic a little here:
http://d.puremagic.com/issues/show_bug.cgi?id=596

Bye,
bearophile

On 09/24/2012 01:36 AM, bearophile wrote:
> Timon Gehr:
>
>> cases already introduce their own scopes in D,
>
> Thank you, I didn't remember this.
>
>
>> but switch cannot be extended well to serve such use cases.
>
> Please explain, as I am not able to see the problems.
>

Switch is syntax sugar for jump tables. An adequate pattern matching
construct would not require explicit control flow statements, and it
would be an expression of arbitrary type.

> I have discussed that topic a little here:
> http://d.puremagic.com/issues/show_bug.cgi?id=596
>
> Bye,
> bearophile

Timon Gehr:

> Switch is syntax sugar for jump tables. An adequate pattern matching
> construct would not require explicit control flow statements, and it would be an expression of arbitrary type.

Introducing a good pattern matching syntax in D requires the introduction of a good amount of complexity. This idea was discussed few times in past.

D switches also work on strings, wstrings, dstrings, so the idea of extending them to work on small array is not too much different.

I think that switching on structs, and tuples with auto-assignment of variables for tuple fields, is enough to extend the usefulness of D switches significantly, while it introduces no new keywords, and not a lot of complexity for both the compiler and the programmer that has to learn D language.

Bye,
bearophile

Le 24/09/2012 01:28, Timon Gehr a écrit :
> I agree with Andrei. Single element tuples need to support the same
> operations as tuples of other arities do.

Obviously it should. The whole point is that you can implicitly cast a 1 element tuple into the element and vice versa.

like :
(int) a = (3); // a is a tuple of 1 element.
int b = a; // Implicit tuple unpack.
a = b; // Implicit tuple packing.

Le 24/09/2012 01:23, Timon Gehr a écrit :
> I assume named tuple fields are not a problem?

I'm not sure it is really usefull.

> 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)));
> }
>

The template syntax seems weird. Why do you want Foo((U...,)) when Foo(U) could do it ?

Le 24/09/2012 01:34, bearophile a écrit :
> Andrei Alexandrescu:
>
>> 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.
>
> As I have tried to explain in my precedent post, Kenji's patch covers
> about 1/4 of the most important use cases.
>

It would be great if we stopped to base design reflection on actual implementations we have somewhere.