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.
