On Monday, 23 December 2013 at 13:58:13 UTC, JR wrote:
> ... I have *almost* understood the difference between built-in tuples, Tuple and TypeTuple.

I had this feeling probably 5 or 6 times in past few years, only to find some new surprise every time :D Can only hope that finally got it right in my mind now.

On Monday, 23 December 2013 at 14:00:21 UTC, Dicebot wrote:
> On Monday, 23 December 2013 at 13:50:26 UTC, monarch_dodra wrote:
>> Ok... Then that'll break existing code that doesn't even *use* TypeTuple... Seems lose-lose to me :/
>
> Yes, this DIP defines breaking transition that requires user action at some point. It is expected and approved by Andrei - we agreed that existing situation is even worse. But std.typetuple will remain as-is during deprecation process so there will be lot of time to do the change.

My issue about this is that it will break existing code that doesn't even use the type "TypeTuple". What are the gains of:

anySatisfy!(someTrait, TemplateArgumentList!(int, double));
over
anySatisfy!(someTrait, int, double)

Or

anySatisfy!(someTrait, TemplateArgumentList!(Args));
over
anySatisfy!(someTrait, Args)

>> I see value in having a packed type with explicit auto-expand, but I don't really see why it should replace the language's built-in variadic type list.
>
> It does not replace built-in one. This DIP does not touch language itself at all and it is stated several times. Only thing which gets replaced is std.typetuple in Phobos and documentation.

No, it doesn't "replace" the language feature itself, but is replacing the *useage* itself. It's kind of like saying (hyperbole, sorry):

"ref" is bad, as of now on, we use "PassByReference!" everywhere, and the caller code needs to migrate to PassByReference!, or the code won't compile anymore. But we aren't replacing the language feature "ref". YOU can still use it if YOU want to. YOU just won't be able to call any of OUR code with it...

end hyperbole.

>> In any case, let me re-write my question it as:
>>
>> staticIndexOf(int, TemplateArgumentList!(TemplateArgumentList!(int, double), int));
>>
>> This time, its legal, right?
>>
>> Only the "outer" TAL gets auto-expanded, right?
>
> Neither. But if you want to expand inner to create monotone list, you can do it explicitly:
>
> staticIndexOf(int, TemplateArgumentList!(TemplateArgumentList!(int, double).expand, int));
>
> // result is 0

Hum... In my eyes, the "Outer" TAL gets expanded by "staticIndexOf". I'm not sure why you say "neither"?

>> With that said, I can only image that the implementation of templates that simply recurse would become very hard to imlement.
>
> Can you give an example? I suspect you may over-complicate things a bit :)

Yes, actually, I think I did over complicate things. Never-mind my above point :)

Still, I don't see how this:

//----
template anySatisfy(alias F, T...)
if (T.length == 1 && isTemplateArgumentList!(T[0]))
{
    alias Args = T[0].expand;

    static if(Args.length == 0)
    {
        enum anySatisfy = false;
    }
    else static if (Args.length == 1)
    {
        enum anySatisfy = F!(Args[0]);
    }
    else
    {
        enum anySatisfy =
            anySatisfy!(F, isTemplateArgumentList!(Args[ 0  .. $/2])) ||
            anySatisfy!(F, isTemplateArgumentList!(Args[$/2 ..  $ ]));
    }
}
//----

Is better than:

//----
template anySatisfy(alias F, T...)
{
    static if(T.length == 0)
    {
        enum anySatisfy = false;
    }
    else static if (T.length == 1)
    {
        enum anySatisfy = F!(T[0]);
    }
    else
    {
        enum anySatisfy =
            anySatisfy!(F, T[ 0  .. $/2]) ||
            anySatisfy!(F, T[$/2 ..  $ ]);
    }
}
//----

I see no gains, but I see complication in both implementation and call code. The TAL just gets in *everyone's* way, with no net benefit (in this context).

----------------

Futhermore, I don't see where you'd draw the line. You proposal (this is still all about your proposal 5), wants to make std.typetuple use TAL's in all their implementations. But what about things like std.tuple.Tuple. Will that also require:

Tuple!(TemplateArgumentList!(int, double, double)) myTuple?

My point is that it seems (to me) that in this specific case, it is forcing the usage of a library type, where the built-in one works perfectly fine :/

I *LIKE* the idea of a PackedTemplateArgumentList, but I think it's usage should far from systematic.

I'm also fine with forcing the equivalent `TypeTuple` to explicit-expand when you use, to reduce ambiguity about packaging. But the language has a built-in "Template Argument List". *That*'s what we should be using when calling them.

On Monday, 23 December 2013 at 15:34:07 UTC, monarch_dodra wrote:
You proposal
> (this is still all about your proposal 5), wants to make std.typetuple use TAL's in all their implementations.

I mean "interface".

On 12/23/2013 12:59 PM, Dicebot wrote:
> On Monday, 23 December 2013 at 11:50:08 UTC, Timon Gehr wrote:
>> This misunderstanding arose because the name of the construct is
>> misleading.
>
> Can explain this a bit? What makes one miss distinction between language
> term and library type?

(It is not a type.)

"At the same time automatic expansion of `TypeTuple` is considered both unhygienic and not consistent with `std.typecons.Tuple`. Fixing it will allow some new template algorithms while still keeping "tuple" library type count at two."

=> the new construct will not auto-expand.

"Why that weird long name, `TemplateArgumentList`

A: Because it is exactly what it is. This name makes it clear that one may expect from this thing behavior similar to http://dlang.org/template.html#TemplateArgumentList"

=> the new construct will behave like the built-in

Together this yields that the built-in will not auto-expand.

> (Hint: latter is denoted by CamelCase ;))

As is the former. :P
http://dlang.org/template.html#TemplateArgumentList


I think using the name TemplateArgumentList for anything other than a shallow wrapper around a template argument list does not actually improve the naming situation.

On Mon, Dec 23, 2013 at 02:04:52PM +0000, Dicebot wrote:
> On Monday, 23 December 2013 at 13:58:13 UTC, JR wrote:
> >... I have *almost* understood the difference between built-in tuples, Tuple and TypeTuple.
> 
> I had this feeling probably 5 or 6 times in past few years, only to find some new surprise every time :D Can only hope that finally got it right in my mind now.

It's one of those things that the more you understand, the more you understand how much you *don't* understand. :P

First there's the word "tuple" that's thrown around with multiple incompatible meanings, then you learn that "tuple" is not the same as "Tuple", and that "TypeTuple" is an alias for "tuple". Then you learn that "TypeTuple" can contain literals as well as types, contrary to its name. Then you learn about something called "parameter tuple" which *seems* to work like "tuple" aka "TypeTuple", except that it doesn't. And then ...


T

-- 
The two rules of success: 1. Don't tell everything you know. -- YHL

On Monday, 23 December 2013 at 15:59:10 UTC, Timon Gehr wrote:
> As is the former. :P
> http://dlang.org/template.html#TemplateArgumentList
>
>
> I think using the name TemplateArgumentList for anything other than a shallow wrapper around a template argument list does not actually improve the naming situation.

This too also bothers me. I'd be more comfortable with (the even longer):
"PackedTemplateArgumentList".

On 12/23/13, Dicebot <public@dicebot.lv> wrote:
> http://wiki.dlang.org/DIP54

I'm waiting to see what others who use TypeTuples think of the DIP. E.g. Philippe Sigaud, David Nadlinger, Hara Kenji, Martin Nowak, Don Clugston, David Simcha, Steven Schveighoffer, etc. I'm pretty sure (most) of these guys use tuples a lot.

Btw, is there a collection of links to the previous topics? It would be worth linking to them from the DIP.

On 12/23/13 4:07 AM, bearophile wrote:
> Jakob Ovrum:
>
>> One tuple and two compile-time lists - where the auto-expanding one
>> covers the vast majority of use cases - doesn't sound at all bad.
>
> Plus built-in syntax to unpack tuples in various situations.

I don't think "various situations" is a good idea. It often does make code shorter. But it means more rules to be defined, implemented, and taught.

Andrei

On 12/23/13 4:25 AM, Dicebot wrote:
> On Monday, 23 December 2013 at 12:03:05 UTC, ilya-stromberg wrote:
>> Can we add alias for `auto-expansion TypeTuple` and add link to the
>> previous documentation like this:
>>
>> alias ExpandedTemplateArgumentList(T) = TemplateArgumentList!(T).expand;
>>
>> It looks like it can fix all objections here.
>
> What is this supposed to give over just using .expand directly? I have
> not seen a good rationale that justifies it among existing objections,
> probably have missed it.

I also think that implicit expansion should not be frequent enough to justify its own abstraction.

Andrei

On 12/23/13 5:41 AM, Maxim Fomin wrote:
> Personally I am upset when I get some weird Phobos structure which
> simulates language feature, rathen then having feature in the language
> in first place.

It's a fine line to thread. Erring on either side is easy and with bad consequences.

Andrei