On 8/19/13 12:54 PM, bearophile wrote:
> Meta:
>
>> It *could* be an underscore; the only thing is that the underscore is
>> a valid variable name, so the above expression would actually be
>> binding two variables, which might surprise someone who was expecting
>> otherwise. I don't really care all that much, but it's something to
>> think about.
>
> You can't define a variable more than once in a scope, so this can't be
> valid:
>
> void main() {
>      auto t1 = #(5, "hello", 1.5);
>      auto (_,  _, x) = t1;
>      auto (_, gr, _) = t1;
> }
>
>
> While ? defines nothing, so this is OK:
>
> void main() {
>      auto t1 = #(5, "hello", 1.5);
>      auto (?,  ?, x) = t1;
>      auto (?, gr, ?) = t1;
> }
>
> Bye,
> bearophile

It's stuff like this that's just useless and gives a bad direction to the whole discussion. There's hardly anything wrong with auto x = t1[2] or auto gr = t1[1], but once the bikeshed is up for painting, the rainbow won't suffice.


Andrei

On 8/19/13 1:41 PM, Dicebot wrote:
> On Monday, 19 August 2013 at 20:36:10 UTC, Andrei Alexandrescu wrote:
>> On 8/19/13 11:14 AM, Dicebot wrote:
>>> On Monday, 19 August 2013 at 18:11:34 UTC, Andrei Alexandrescu wrote:
>>>> I'd call them alias tuples.
>>>
>>> Because we don't have strict definition of alias too? :)
>>
>> I'm thinking such a tuple may hold everything that one may define an
>> alias to.
>
> Normal alias or template alias parameter? ;)

Normal alias. Yah, perhaps "template tuples" are more descriptive.

Andrei

On Monday, 19 August 2013 at 20:46:02 UTC, Andrei Alexandrescu wrote:
> It's stuff like this that's just useless and gives a bad direction to the whole discussion. There's hardly anything wrong with auto x = t1[2] or auto gr = t1[1], but once the bikeshed is up for painting, the rainbow won't suffice.

I started this discussion to build on Kenji's DIP, which discusses destructuring and pattern matching syntax in addition to tuple literal syntax, as well as the previous discussion that's already gone on in the two "DIP discussion" threads. Are you saying that you dislike the destructuring/pattern matching discussion as a whole?

Andrei Alexandrescu:

> It's stuff like this that's just useless and gives a bad direction to the whole discussion. There's hardly anything wrong with auto x = t1[2] or auto gr = t1[1], but once the bikeshed is up for painting, the rainbow won't suffice.

I was just explaining why _ can't be used as wildcard (unless you also make _ a not valid variable name), it wasn't meant to be an example of why wildcards are useful in the first place.

Bye,
bearophile

On Monday, 19 August 2013 at 20:46:02 UTC, Andrei Alexandrescu wrote:
> It's stuff like this that's just useless and gives a bad
> direction to the whole discussion. There's hardly anything
> wrong with auto x = t1[2] or auto gr = t1[1], but once the
> bikeshed is up for painting, the rainbow won't suffice.

I started this discussion to build on Kenji's DIP, which discusses destructuring and pattern matching syntax in addition to tuple literal syntax, as well as the previous discussion that's already gone on in the two "DIP discussion" threads. Are you saying that you dislike the destructuring/pattern matching discussion as a whole?

I'm saying that there's a mix of useful stuff and just syntactic additions that are arguably less so. In my opinion:

a) destructuring tuples in auto declarations - good to have:

auto (a, b, c) = functionReturningTupleOrStaticArrayWith3Elements();

b) syntactic support for ignoring certain members in a destructuring - is that really needed?

auto (a, ?, c) = functionReturningTupleOrStaticArrayWith3Elements();


Andrei

On Monday, 19 August 2013 at 20:51:47 UTC, Andrei Alexandrescu wrote:
> Normal alias. Yah, perhaps "template tuples" are more descriptive.

And how would you call _instance_ of template tuple then? (which is also built-in tuple but not template tuple)

On Monday, 19 August 2013 at 19:24:32 UTC, Timon Gehr wrote:
> On 08/19/2013 07:44 PM, H. S. Teoh wrote:
>> Well, OK, whatever they're supposed to be called. Compiler-tuples, or
>> expression tuples, or whatever. See, part of the problem is that they
>> just don't have any good name that correctly conveys what they are.
>>
>
> They are simply template argument lists.
>
> (http://wiki.dlang.org/The_D_Programming_Language/Seq)

Nice short FAQ for one of the more confusing parts of D.  The name "template argument list" clears things up quite a bit actually (but is too long for a type name).  Is it your idea to use Seq instead of TypeTuple?

On Monday, 19 August 2013 at 21:03:50 UTC, Andrei Alexandrescu wrote:
> I'm saying that there's a mix of useful stuff and just syntactic additions that are arguably less so.

Wanted to note here that while discussing syntax at this moment is indeed mostly useless but playing with imaginary code snippets does help to understand what behavior people want to see and that can be used as a basis for formalizing semantics.

On Monday, 19 August 2013 at 21:16:43 UTC, Brad Anderson wrote:
> On Monday, 19 August 2013 at 19:24:32 UTC, Timon Gehr wrote:
>> On 08/19/2013 07:44 PM, H. S. Teoh wrote:
>>> Well, OK, whatever they're supposed to be called. Compiler-tuples, or
>>> expression tuples, or whatever. See, part of the problem is that they
>>> just don't have any good name that correctly conveys what they are.
>>>
>>
>> They are simply template argument lists.
>>
>> (http://wiki.dlang.org/The_D_Programming_Language/Seq)
>
> Nice short FAQ for one of the more confusing parts of D.  The name "template argument list" clears things up quite a bit actually (but is too long for a type name).  Is it your idea to use Seq instead of TypeTuple?

Pretty heavy on the snark though :P

On Monday, 19 August 2013 at 21:03:50 UTC, Andrei Alexandrescu wrote:
> I'm saying that there's a mix of useful stuff and just syntactic additions that are arguably less so. In my opinion:
>
> a) destructuring tuples in auto declarations - good to have:
>
> auto (a, b, c) = functionReturningTupleOrStaticArrayWith3Elements();
>
> b) syntactic support for ignoring certain members in a destructuring - is that really needed?
>
> auto (a, ?, c) = functionReturningTupleOrStaticArrayWith3Elements();

In fairness, it is very common in other languages with pattern matching/destructuring. Off the top of my head I can think of Haskell, ML, Racket, Javascript (destructuring only) and Rust. This syntax is more important when pattern matching, but also seems to be almost universally used in destructuring. From the DIP:

switch (tup) {
    case {1, 2}:
    case {$, 2}: //Don't care what the first value is, only match on second
    case {1, x}:
    default:
}

You could just replace {$, 2} with {x, 2} and never use x, but this creates the problem that Bearophile mentioned.

auto t1 = #(5, "hello", 1.5); //Fine
auto #(_,  _, x) = t1; //Dammit, can't use _ twice as it's a variable

If you replace _ with throwaway variable names, it becomes much less clear (IMO) exactly what is going on. Any programmer reading your code would have to examine the function to see if the bindings introduced are ever used, or if they are just throwaways.

Maybe it's unproductive to argue over the colour of the bike shed, but we need to know whether it's worth adding windows.