On Friday, 16 August 2013 at 16:28:29 UTC, H. S. Teoh wrote:
> This can be part of the solution, but by itself is not good enough,
> because the so-called "typetuple" and std.typecons.

Key point is that having proper built-in syntax for type/expression tuples obsoletes the need in TypeTuple and it can be deprecated completely.

On Friday, 16 August 2013 at 16:19:51 UTC, Dicebot wrote:
>>
>> Add the built-in t{} syntax to denote all kind of tuples.
>
> This. With an exception of "I don't care what syntax is".
/snip
> What was the general attitude to http://wiki.dlang.org/DIP32 ?

I don't like the "t".  I'd prefer just using parentheses, but I think there were readability problems that caused the DIP to end up with:
> "Basic () syntax, perhaps the cleanest, but can't be used:"
Though there's nothing else written about that.

The DIP itself, though, looks pretty good.

-Wyatt

On Friday, August 16, 2013 18:08:36 bearophile wrote:
> John Colvin:
> > Possible solutions:
> My vote is for solution n.5:
> 
> Add the built-in t{} syntax to denote all kind of tuples.

Since the built-in tuples / std.typetuple.TypeTuple and std.typecons.Tuple are fundamentally different, I don't see how you could possibly combine the two in a single syntax. You'd need different syntaxes for each one.

- Jonathan M Davis

On Friday, 16 August 2013 at 19:19:19 UTC, Jonathan M Davis wrote:
> Since the built-in tuples / std.typetuple.TypeTuple and std.typecons.Tuple
> are fundamentally different, I don't see how you could possibly combine the two
> in a single syntax. You'd need different syntaxes for each one.

The fact that std.typetuple.TypeTuple and built-in ones are different is most inconvenient thing in all this situation. They should be the same and TypeTuple removed as redundant.

On Friday, August 16, 2013 21:23:26 Dicebot wrote:
> On Friday, 16 August 2013 at 19:19:19 UTC, Jonathan M Davis wrote:
> > Since the built-in tuples / std.typetuple.TypeTuple and
> > std.typecons.Tuple
> > are fundamentally different, I don't see how you could possibly
> > combine the two
> > in a single syntax. You'd need different syntaxes for each one.
> 
> The fact that std.typetuple.TypeTuple and built-in ones are different is most inconvenient thing in all this situation. They should be the same and TypeTuple removed as redundant.

But TypeTuple and the built-in ones _aren't_ different. TypeTuple is an alias for the built-in ones that's required because of the lack of syntax for declaring them on their own. TypeTuple could just have easily been called BuiltInTuple (and would probably have been better named as such, even though that name isn't exactly great). It's std.typecons.Tuple which is different.

Adding a syntax for TypeTuple, making TypeTuple redundant would be great, but Bearophile seems to be arguing that having some sort of tuple syntax would make it so that we don't need TypeTuple and Tuple, which is wrong, because they're different. If you're creating a new syntax in the language for one of them, you only get rid of the need for one of them in the library, not both. The idea of a "universal tuple" (like Bearophile seems to be looking for) makes no sense given the differences between the built-in tuples and Tuple.

- Jonathan M Davis

On Fri, Aug 16, 2013 at 03:35:40PM -0400, Jonathan M Davis wrote: [...]
> Adding a syntax for TypeTuple, making TypeTuple redundant would be great, but Bearophile seems to be arguing that having some sort of tuple syntax would make it so that we don't need TypeTuple and Tuple, which is wrong, because they're different. If you're creating a new syntax in the language for one of them, you only get rid of the need for one of them in the library, not both.  The idea of a "universal tuple" (like Bearophile seems to be looking for) makes no sense given the differences between the built-in tuples and Tuple.
[...]

This is why I don't like the term "tuple". It's using a single word to describe apples and oranges. It gives you the wrong idea that there's some kind of underlying, unifying thing common to both, but there isn't! We really need to start using different terms to refer to them, otherwise the confusion will only continue.

If I could roll back time, I'd rename std.range.Tuple to std.range.AnonStruct, because that's what it is -- an anonymous struct that you put together on-the-spot by stringing a bunch of values together. It has nothing to do with what DMD calls a "tuple" (except that compile-time tuples, or CT-tuples, are used to implement it, but that's an irrelevant implementational detail).

But I don't have a time machine, sad to say, and there's also precedent for "tuple" in other languages in relation to what std.range.Tuple does, so I'm expecting "tuple" will stick in this case.

Which leaves the compile-time thingies in need of a new, DIFFERENT name. Ali's suggestion, SymbolTuple, is nice, but still has that dreaded "tuple" in it, which still suggests some kind of conflation with std.range.Tuple. I think we should avoid any name containing "tuple" for these things. What about SymbolList? (maybe TypeList, but it's misleading because it isn't restricted to types alone; plus I want to avoid "sequence" in order to prevent the same confusion with std.range.sequence).

Or maybe we should call them "tuplets" with a T (as in "quintuplet"). Or "compile-time tuplets" (CT-tuplets), to distinguish them from Tuples. The diminutive -t ending being a reference to the fact that they are compile-time-only constructs, hence not "full-fledged Tuples".


T

-- 
Error: Keyboard not attached. Press F1 to continue. -- Yoon Ha Lee, CONLANG

On Friday, 16 August 2013 at 19:35:56 UTC, Jonathan M Davis wrote:
> But TypeTuple and the built-in ones _aren't_ different. TypeTuple is an alias
> for the built-in ones that's required because of the lack of syntax for
> declaring them on their own.

That is intention but not implementation. There some cases where you can simply enumerate stuff via comma but can't use TypeTuple. There are cases where you can use TypeTuple but can't express the same thing with any built-in syntax. Recent discoveries on topic in bugzilla and digitalmars.learn have really frustrated me and I have considered myself somewhat experienced D user.

> Adding a syntax for TypeTuple, making TypeTuple redundant would be great, but
> Bearophile seems to be arguing that having some sort of tuple syntax would
> make it so that we don't need TypeTuple and Tuple..

Does he? I missed that from his comments. bearophile, is that true? :)

std.typecons.Tuple should be left untouched, of course, because it serves important goal - constructing a type (as module name suggests), something that can be used in ABI realm. It can make use of better integration with built-in tuples but it is a distinct topic.

On Friday, 16 August 2013 at 20:22:49 UTC, H. S. Teoh wrote:
> ...

Term "tuple" comes from math and means "ordered set of elements". In that sense anonymous struct with unnamed fields _is_ a tuple and I thing std.typecons.Tuple is the place where naming is fine.

It is re-using the term for compile-time entity of the language that causes confusion. While it matches the mathematical definition of "tuple" too, its practical meaning for language is much more than that and naming should express it.

I was just thinking about the whole Tuple situation today. I think I might write up a quick, somewhat-related post.

As for TypeTuple, I agree that it is not a good name at all for what it does. It confused me endlessly when I first started learning D. There are still corner cases where it's not at all obvious what's going on. See Ali's thread in D.Learn about assigning a TypeTuple to an enum. Things got weird.

I think in Andrei's Modern C++ book there was a similar concept called Type Lists. That's still not a great name, as TypeTuple can contain more than just types. Maybe ExpressionList/ExprList?

On Friday, August 16, 2013 22:30:11 Dicebot wrote:
> On Friday, 16 August 2013 at 20:22:49 UTC, H. S. Teoh wrote:
> > ...
> 
> Term "tuple" comes from math and means "ordered set of elements". In that sense anonymous struct with unnamed fields _is_ a tuple and I thing std.typecons.Tuple is the place where naming is fine.
> 
> It is re-using the term for compile-time entity of the language that causes confusion. While it matches the mathematical definition of "tuple" too, its practical meaning for language is much more than that and naming should express it.

In addition, the built-in tuples are not at all what most programmers think about when they think about tuples. Tuples are supposed to be nestable, whereas the built-in tuples are always flat. So, if anything, it's calling the built-in tuples tuples which is the problem. "Sequence" seems to be a semi- popular suggestion for a better term whenever it comes up, but that poses its own set of difficulties.

- Jonathan M Davis