On Monday, 24 March 2014 at 16:59:37 UTC, bearophile wrote:
> void foo(in auto tuple(a, b, c)) {}

This snippet does not make any sense.

Dicebot:

> 	int a, b, c;
> 	
> 	tuple(a, b, c) = foo();
> 	writeln(a, b, c); // 000
> 	
> 	TypeTuple!(a, b, c) = foo();
> 	writeln(a, b, c); // 123
> }

One of the points of a good tuple syntax is to not need to define the variables before (because in several cases you can't do that).


> On Monday, 24 March 2014 at 16:59:37 UTC, bearophile wrote:
>> void foo(in auto tuple(a, b, c)) {}
>
> This snippet does not make any sense.

It's equivalent to Python2.6 code:

def foo((a, b, c)):


A more complete Python2.6 program:

def foo((a, b, c)):
    print a, "-", b, "-", c

t = (10, 20, 30)
foo(t)

Output:

10 - 20 - 30


In Haskell, OcaML, and other languages the code is similar. It's a tuple unpacking syntax in the function signature.

The other example with foreach is very similar.

Bye,
bearophile

On Monday, 24 March 2014 at 17:35:46 UTC, bearophile wrote:
> Dicebot:
>
>> 	int a, b, c;
>> 	
>> 	tuple(a, b, c) = foo();
>> 	writeln(a, b, c); // 000
>> 	
>> 	TypeTuple!(a, b, c) = foo();
>> 	writeln(a, b, c); // 123
>> }
>
> One of the points of a good tuple syntax is to not need to define the variables before (because in several cases you can't do that).

I understand but this is something that can be pretty hard to fit into D semantics/grammar and I am not sold that it is worth the push on its own.

>> On Monday, 24 March 2014 at 16:59:37 UTC, bearophile wrote:
>>> void foo(in auto tuple(a, b, c)) {}
>>
>> This snippet does not make any sense.
>
> It's equivalent to Python2.6 code:
>
> def foo((a, b, c)):
>
>
> A more complete Python2.6 program:
>
> def foo((a, b, c)):
>     print a, "-", b, "-", c
>
> t = (10, 20, 30)
> foo(t)
>
> Output:
>
> 10 - 20 - 30

What is the difference with this then?

void foo(int a, int b, int c)
{
    // ...
}

auto t = tuple(10, 20, 30);
foo(t.expand);

Dicebot:

> I understand but this is something that can be pretty hard to fit into D semantics/grammar and I am not sold that it is worth the push on its own.

I'd like a good tuple syntax in D.


> What is the difference with this then?
>
> void foo(int a, int b, int c)
> {
>     // ...
> }
>
> auto t = tuple(10, 20, 30);
> foo(t.expand);

The difference is that your experience with tuples will be less good. One difference can be seen here. Given an array of tuples (here I am using a shorter syntax):

auto arr = [@{1, 2}, @(3, 4)]

You can't do this:

void foo(int a, int b, int c) {...}
auto result = arr.map!foo;

And you need:

auto result = arr.map!(t => foo(t.expand));

Or:

auto result = arr.map!(t => foo(t[]));


While you can do this:

void foo(in @(int a, int b, int c}) {...}
auto result = arr.map!foo;

The point of having a tuple syntax is not to expand the set of programs you can write with C language. It's of having a handy syntax to perform certain very common operations with more than one type.

I also suggest you to take a look at the DIP.

Bye,
bearophile

On Monday, 24 March 2014 at 17:51:15 UTC, bearophile wrote:
> The difference is that your experience with tuples will be less good. One difference can be seen here. Given an array of tuples (here I am using a shorter syntax):
>
> auto arr = [@{1, 2}, @(3, 4)]
>
> You can't do this:
>
> void foo(int a, int b, int c) {...}
> auto result = arr.map!foo;
>
> And you need:
>
> auto result = arr.map!(t => foo(t.expand));
>
> Or:
>
> auto result = arr.map!(t => foo(t[]));
>
>
> While you can do this:
>
> void foo(in @(int a, int b, int c}) {...}
> auto result = arr.map!foo;

I believe it is dangerous misfeature and I don't want to see this in D. Sorry :(

Dicebot:

>> While you can do this:
>>
>> void foo(in @(int a, int b, int c}) {...}
>> auto result = arr.map!foo;
>
> I believe it is dangerous misfeature and I don't want to see this in D. Sorry :(

Why do you think it's a dangerous and a misfeature? I think you are misaken.

It's present in most functional languages, with slight syntax differences.

The problem is that it's hard to explain how much nice a language feature is if you have not used it extensively in some language :-) So I suggest you to try to write some functional code that uses plenty of tuples. You will see how commonly useful is what I have written :-)

A similar program in Haskell:


foo (a, b) =
    show a ++ " - " ++ show b

lst = [(10, 20), (30, 40)]

main = do
    print $ map foo lst


Output:

["10 - 20","30 - 40"]

And Haskell is regarded as one of the safest languages :-)

Similar code is possible in F#, OCaml, Scala, etc.

Bye,
bearophile

On Monday, 24 March 2014 at 16:40:29 UTC, Andrei Alexandrescu wrote:
> On 3/24/14, 5:25 AM, w0rp wrote:
>> Please kill the comma operator with fire. Is is just bad.
>>
>> On Monday, 24 March 2014 at 12:20:11 UTC, Marc Schütz wrote:
>>> Or, if you really want to distinguish them, this would work:
>>>
>>> (1,2)    two-element tuple
>>> (1,)     one-element tuple
>>> (1)      simple expression
>>> (,)      empty tuple
>>
>> I am a regular Python user, and I advise against using this syntax for
>> tuples. I have been bitten many times by something which I thought was a
>> tuple becoming an expression and something I thought was a simple
>> expression becoming a tuple. It may be less of an issue in a static
>> language, but it will still be an issue. I don't have an alternative
>> syntax to propose.
>
> How about
>
> tuple(1,2)    two-element tuple
> tuple(1)      one-element tuple
> (1)           simple expression
> tuple()       empty tuple
>
> Oh, wait...
>
>
> Andrei

Yes, I am with you on this. I prefer tuple(1) over (1, )

w0rp:

> Yes, I am with you on this. I prefer tuple(1) over (1, )

I don't think people are advocating for the "(1, )" syntax. Regarding the "tuple(1)" syntax, it is one of the alternative syntaxes you can find in the DIP. One disadvantage of the "tuple()" syntax is that it's a little long, so if you have an array of tuple literals it becomes a little wordy:

auto a = [tuple(1, 2), tuple(3, 4), tuple(5, 6)];

But of course having a good built-in "tuple()" syntax is much better than the current situation without any syntax.

Bye,
bearophile

On 2014-03-24 16:42:59 +0000, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> said:

> tuple()
> tuple(a)
> tuple(a, b)
> tuple(a, b, c)

struct()
struct(a)
struct(a, b)
struct(a, b, c)

Tuples are actually nameless structs, no?

-- 
Michel Fortin
michel.fortin@michelf.ca
http://michelf.ca

Michel Fortin:

> struct()
> struct(a)
> struct(a, b)
> struct(a, b, c)
>
> Tuples are actually nameless structs, no?

That syntax is even longer/wordier :-)

auto arr = [struct(1, 2), struct(3, 4), struct(5, 6)];

Structs usually don't support slicing and concatenation. But they are indeed related structures.

Bye,
bearophile