Issue 9608 - Implement template parameter introspection traits

[AndrejMitrovic]

Implements https://issues.dlang.org/show_bug.cgi?id=9608

Recreated from #3515

As @andralex suggested, we could keep these undocumented for now and expose them in std.traits and/or use them only internally until we're ok with supporting and documenting these new features.

[dlang-bot]

Fix	Bugzilla	Description
✓	9608	Add introspection for templates

[andralex]

Status of this?

[jacob-carlborg]

Does this work for lambdas or templated classes, structs, functions and so on? If that's the case, then I think there should be tests for that.

[AndrejMitrovic]

Status of this?

Needs a rebase. Will do soon.

Does this work for lambdas or templated classes, structs, functions and so on? If that's the case, then I think there should be tests for that.

I'll try them out, stay tuned. :)

[AndrejMitrovic]

Does this work for lambdas or templated classes, structs, functions and so on? If that's the case, then I think there should be tests for that.

It seems to work for everything but lambdas, where it only supports getTemplateParamCount and isTemplateTypeParam.

As far as I can tell lambdas do not support things like type defaults and specializations, or alias parameters. And that kind of makes sense since you can't really "overload" lambdas against each other (although the topic in itself could be interesting).

Rebased against master.

[jacob-carlborg]

Shouldn't isTemplateVariadicParam and getTemplateParamIdent work for lambdas?

[AndrejMitrovic]

Well for some reason for lambdas they all seem to be type parameters. Also, for getTemplateParamIdent the situation is as follows:

alias fun = (a, int b) => a + b;

Here only 'a' is the templated type, and you will get an internal string out of this like __T8, which most likely depends on the internal implementation so it's hard to test.

[jacob-carlborg]

Ok, fair enough. It's not up to this PR to change any behavior.

[jacob-carlborg]

LGTM 👌

[AndrejMitrovic]

@andralex: It's green now.

[MetaLang]

@AndrejMitrovic it's red again

[andralex]

Thanks! I'll toggle approval.

[andralex]

Auto-merge toggled on

[MetaLang]

I submitted a fixed version of this pull request: #5496

[MartinNowak]

Can we please rediscuss the design before adding 10 new traits and 600+LOC.
It seems that most (if not all) use-cases for this would be covered by adding templateParameters and and maybe templateParameterDefaults.
We already have tools to distinguish types from values in AliasSeq, and it should be possible to make __traits(identifier, templateParams[0]) work.
This PR adds a lot of introspection (like accessing param specs) w/ unclear use cases.
If more access is needed we can always add it, but it's hard to take away sth.

Also test cases for overloaded templates are missing. Can those be used with __traits(getOverloads, mod, "template")[1]?

[MartinNowak]

Auto-merge toggled off

[AndrejMitrovic]

templateParameters

The problem I had with this is that we can't get specialization or default values stored in the tuple that this trait would return.

[UplinkCoder]

I agree with @MartinNowak here.
__traits should be added sparingly.
we should keep them as minimalistic as possible.
Futhermore maybe a reevaluation of the __tratis already implemented is in order.
we should not have overlapping functionality.

[MartinNowak]

The problem I had with this is that we can't get specialization or default values stored in the tuple that this trait would return.

What's the use-case for specializations? You could add a separate templateParameterDefaults trait if needed.
Also you've invented a new idiom with __traits(getTemplateSomething, templ, 10) to index a particular parameter of a template, where the actual problem is, that the template parameter details don't have a simple representation.

[AndrejMitrovic]

What introspection features for parameters are we truly missing right now? Let's try to find the use-cases and then implement something based on that. In the meantime we could even close this, it's adding too much in any case.

Also you've invented a new idiom

I better file a new patent.. :P

[AndrejMitrovic]

Ok, I'll start a discussion in the forums soon with a proposal of a (sub)set of the new traits and see which ones we really need, and whether we could implement as many of these in the library instead of adding additional compiler code. Closing for now. :)

[jacob-carlborg]

@AndrejMitrovic any news on this? It's coming up again in the newsgroups: https://forum.dlang.org/post/awjuoemsnmxbfgzhgkgx@forum.dlang.org.

[AndrejMitrovic]

Well of course it does.. :)

Anyway thinking about this I don't really know what another discussion will do. All we'll end up with is a couple of votes in favor, a couple against, and then a big off-topic thread derailment.

Implementation-wise this isn't a complex feature, anyone could submit another PR with a subset of features introduced here. And then later one could add more support when it's needed..

[jacob-carlborg]

Implementation-wise this isn't a complex feature, anyone could submit another PR with a subset of features introduced here. And then later one could add more support when it's needed..

I think that's a good start. Perhaps get the number of parameters and the names for a lambda/template function.

[AndrejMitrovic]

Yes let's do it piece-meal and introduce one trait at a time.

[jacob-carlborg]

@AndrejMitrovic came up again [1]. Any progress?

[1] http://forum.dlang.org/post/zlkbvnrfncokhzpmtlfn@forum.dlang.org

[jll63]

I'm still very interested in this. It would make templatized open methods much nicer.

[andralex]

Revived interest in the forum: https://forum.dlang.org/post/rfjr11$2uj6$1@digitalmars.com