DIP54 : revamp of Phobos tuple types

[monarch_dodra]

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.