On 3/29/13, kenji hara <k.hara.pg@gmail.com> wrote:
> http://wiki.dlang.org/DIP32
>
> Kenji Hara
>

<quote>
And, this syntax (currently it is not enough documented)
foreach (x, y; zip([1,2,3], ["a","b","c"])) {}
</quote>

Well that kinda sucks, I was just getting used to this syntax..But for me it it was too magical to begin with, so I have no real complaints.

<quote>
if (auto {1, y} = tup) {
    // If the first element of tup (tup[0]) is equal to 1,
    // y captures the second element of tup (tup[1]).
}
</quote>

That looks like black magic to me.

<quote>
int x = 1;
if (auto {$x, y} = coord) { ... }
// If the first element of coord is equal to 1 (== x), 'then'
statement wil be evaluated.
</quote>

I really don't think we need this magic.. It feels like D and Perl had lots of booze and made it to the mile-high club, and one of them got pregnant.

I just thinks this adds way too many features at once. I'd argue we should take it slow and start with some basic ability to define and unpack tuples, and then gradually add these other features *if* they're really wanted.

The new meaning of $ and $var and literals in if statements and "...", is just too much for me to take.

Andrej Mitrovic:

> <quote>
> And, this syntax (currently it is not enough documented)
> foreach (x, y; zip([1,2,3], ["a","b","c"])) {}
> </quote>
>
> Well that kinda sucks, I was just getting used to this syntax..But for
> me it it was too magical to begin with, so I have no real complaints.

I have recently asked to remove that from the language, because it's not flexible and it has problems:
http://d.puremagic.com/issues/show_bug.cgi?id=9817


> It feels like D and Perl had
> lots of booze and made it to the mile-high club, and one of them got pregnant.

Perl is hermaphrodite, after all.


> <quote>
> if (auto {1, y} = tup) {
>     // If the first element of tup (tup[0]) is equal to 1,
>     // y captures the second element of tup (tup[1]).
> }
> </quote>
>
> That looks like black magic to me.
>
> <quote>
> int x = 1;
> if (auto {$x, y} = coord) { ... }
> // If the first element of coord is equal to 1 (== x), 'then'
> statement wil be evaluated.
> </quote>
>
> I really don't think we need this magic..
> ...
> I just thinks this adds way too many features at once. I'd argue we
> should take it slow and start with some basic ability to define and
> unpack tuples, and then gradually add these other features *if*
> they're really wanted.

I kind of agree. In my answer to Kenji I have suggested to split the DIP into two DIPs, Stage1 and Stage2 and move four features in the second Stage. This will have several advantages, for their design, implementation and learning.


> The new meaning of $ and $var and literals in if statements and "...",
> is just too much for me to take.

In my answer to Kenji I have suggested possible alternatives.

Bye,
bearophile

On Fri, 29 Mar 2013 09:57:51 +0100, kenji hara <k.hara.pg@gmail.com> wrote:

> http://wiki.dlang.org/DIP32

Good stuff! I agree with Andrej Mitrovic that 'if (auto {1, y} = tup)'
looks a tad weird, and 'if (auto {$x, y} = coord)' is even worse.

Frankly, I feel 'if' is the wrong vessel for pattern matching. Switch/case
is perfect. It reads sensibly, and there is no confusion of assignment and
comparison operators.


....Perhaps what's needed is simply a different operator:

if (auto {1, y} : tup)
if (auto {$x, y} : tup)

That feels more sensible to me. Mayhap : is not the best choice, but =
feels wrong to me. I'm sure I could get used to it, but it seems to me that
the return value of 'auto {1, y} = tup' should be a tuple, not a boolean
value.

The $ still feels weird, but I'm all out of better ideas.


All in all, I really like this, but agree with bearophile that some parts
may be better left for a future DIP. For now, unpacking and switch pattern
matching would be awesome.

-- 
Simen

Simen Kjærås:

> All in all, I really like this, but agree with bearophile that some parts may be better left for a future DIP.

On the other hand it's important that the Stage1 DIP should be designed to not make it impossible to add future tuple enhancements. So a draft of the Stage2 should be written from the start, to have a more global vision of the situation.

Bye,
bearophile

2013/3/29 Andrej Mitrovic <andrej.mitrovich@gmail.com>

> On 3/29/13, kenji hara <k.hara.pg@gmail.com> wrote:
> > http://wiki.dlang.org/DIP32
> >
> > Kenji Hara
> >
>
> <quote>
> And, this syntax (currently it is not enough documented)
> foreach (x, y; zip([1,2,3], ["a","b","c"])) {}
> </quote>
>
> Well that kinda sucks, I was just getting used to this syntax..But for me it it was too magical to begin with, so I have no real complaints.
>
> <quote>
> if (auto {1, y} = tup) {
>     // If the first element of tup (tup[0]) is equal to 1,
>     // y captures the second element of tup (tup[1]).
> }
> </quote>
>
> That looks like black magic to me.
>
> <quote>
> int x = 1;
> if (auto {$x, y} = coord) { ... }
> // If the first element of coord is equal to 1 (== x), 'then'
> statement wil be evaluated.
> </quote>
>
> I really don't think we need this magic.. It feels like D and Perl had lots of booze and made it to the mile-high club, and one of them got pregnant.
>
> I just thinks this adds way too many features at once. I'd argue we should take it slow and start with some basic ability to define and unpack tuples, and then gradually add these other features *if* they're really wanted.
>
> The new meaning of $ and $var and literals in if statements and "...", is just too much for me to take.
>

I wrote about it to encourage discussions.

I can agree that $identifier looks weird, but a feature to do it is*necessary*.

When you create a pattern for matching, there is two cases.
- All value part can be represented by literal.
- Some values would be made in runtime.

bool testMatch(T)(int first_value, T tup) {
    if (auto {first_value, ...} = tup) { return true; } else { return
false; }
    // first_value should be replaced to the given function argument,
rather than capturing tup[0]
}
assert(testMatch(1, {1, 2, 3}) == true);
assert(testMatch(2, {1, 2, 3}) == false);

To distinct the capturing and evaluated value, var and $var is necessary.

Syntax for the feature is still debatable.

Kenji Hara

2013/3/29 Simen Kjærås <simen.kjaras@gmail.com>

> if (auto {1, y} : tup)
> if (auto {$x, y} : tup)
>

Hmm, using `:` is good, but it's matching direction is opposite to is(X :
T!TL, alias T, TL...).

Kenji Hara

On 03/29/2013 04:20 PM, kenji hara wrote:
> ...
>
> I can agree that $identifier looks weird, but a feature to do it
> is*necessary*.
> ...

eg. Haskell does not have it. (but it has pattern guards)

Another thing, what do you do if there are multiple matching patterns in a switch?:

final switch({1,2}){
    case {1,y}: ...; break;
    case {x,2}: ...; break;
    default: ...; break;
}

Timon Gehr:

> Another thing, what do you do if there are multiple matching patterns in a switch?:
>
> final switch({1,2}){
>     case {1,y}: ...; break;
>     case {x,2}: ...; break;
>     default: ...; break;
> }

You can't have "default:" in a final switch. The cases must be exhaustive of all possibilities:

final switch({1, 2}) {
    case { 1,  y}: ...; break;
    case { x,  2}: ...; break;
    case {$_, $_}: ...; break;
}


Bye,
bearophile

2013/3/30 Timon Gehr <timon.gehr@gmx.ch>

> eg. Haskell does not have it. (but it has pattern guards)
>
> Another thing, what do you do if there are multiple matching patterns in a switch?:
>
> final switch({1,2}){
>     case {1,y}: ...; break;
>     case {x,2}: ...; break;
>     default: ...; break;
> }
>

The patterns should be tested in lexical order.

Kenji Hara

On Fri, 29 Mar 2013 16:20:14 +0100, kenji hara <k.hara.pg@gmail.com> wrote:

> 2013/3/29 Andrej Mitrovic <andrej.mitrovich@gmail.com>
>
>> The new meaning of $ and $var and literals in if statements and "...",
>> is just too much for me to take.
>>
>
> I wrote about it to encourage discussions.
>
> I can agree that $identifier looks weird, but a feature to do it
> is*necessary*.

How's about ref? As in 'if (auto {ref x, y} : coord)'. It's more consistent
with existing D syntax, and sorta makes sense.

-- 
Simen