Perfect forwarding

[Adam D. Ruppe]

On Sunday, 26 July 2020 at 02:10:19 UTC, Andrei Alexandrescu 
wrote:
> That needs fixed. What primitives would you need for that?

Hmm, hard to say, and I'm also hesitant because it makes template 
optimization even harder - the more of the innards we expose, the 
less the compiler is able to discard, even in theory. (We 
probably will need some kind of specifically restricted template 
at some point as a practical optimization matter. Stefan's not 
wrong about the complications here.)

But anyway, I think we'd have to see at a minimum a list of 
template parameters. Constraint might be useful too, but that can 
be at least tested via __traits(compiles) once you have the 
template parameter list.

The tricky thing is figuring out how to represent them in the 
language. Regular function parameters are not representable 
either... you probably know how awkward it is to get function 
default arguments. (Oh, btw, those of you doing the OP challenge, 
remember default arguments should be forwarded too!) You have to 
make a helper function slicing the params and return the value 
since D doesn't really represent this data, it is more like an 
opaque object you can just use in certain contexts.

But at least with ordinary parameters, you can drill down with 
typeof(param). That would work for template value parameters, but 
what is T? Well, is(T) might help there.

static if(is(Param)) { /* template type param */ }
else static if(is(typeof(Param) Type)) { /* template value param 
*/ }

The big remaining question is an alias param. If we had some kind 
__traits(isAlias) that could be used here as well as in other 
places of reflection. Good idea regardless imo. Then you need to 
be able ot get the alias name itself, not just the identifier of 
what it is an alias of. I think __traits(identifier) and/or 
.stringof can do this now but unable to check as I type this 
email. But should make that formally possible - remember a 
template alias param will not actually be an alias of anything 
yet! Ditto on T, it is a speculative type, not an actual type. So 
regular reflection might not quite work, just it is as close as 
we can get.

And then T... params. That probably needs a specific detection 
too, could be like __traits(isAliasSeq) or something.


So to sum up before my laptop dies:

* a way to get the list of template parameters

* a way to identify the different kinds of template params. Some 
overlap with function parameters is possible but it will be 
tricky because template(T) is not actually a type. But if the 
compiler made it a placeholder type for this purpose then we can 
reuse some of the machinery.

* alias and tuple params could use specific attention, which can 
be written in a general-purpose manner.


Then I think we can make this happen. One of the guys at work has 
hit this trouble before too, perhaps on Monday we can loop him in 
and get a second opinion to see if I missed anything.