www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Template argument deduction not working with template specialization

reply Paul <paultjeadriaanse gmail.com> writes:
While trying to use template specializations I noticed the 
argument deductions do not yield the same version as the ones 
yielded when being explicit.
Example:

 uint a = 1;
 uint[] b = [2];
 TFoo(a);
 TFoo!(uint[])(b);
 void TFoo(T)(T a) {
 	pragma(msg, "T: " ~ T.stringof);
 }
 
 void TFoo(T : T[])(T[] a) {
 	pragma(msg, "T[]: " ~ T.stringof);
 }
I noticed that an automatically deduced TFoo call always yields the first, while TFoo!(uint[]) yields the array version if present, and defaults to the first elsewise. Am I incorrect in expecting the same behavior when (ab)using argument deduction or does my usage make sense? I tried searching for this combination (deduction & specialization) but couldn't find another forum post / documentation example.
Jan 17
next sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 1/17/21 11:22 AM, Paul wrote:
 While trying to use template specializations I noticed the argument 
 deductions do not yield the same version as the ones yielded when being 
 explicit.
 Example:
 
 uint a = 1;
 uint[] b = [2];
 TFoo(a);
 TFoo!(uint[])(b);
 void TFoo(T)(T a) {
     pragma(msg, "T: " ~ T.stringof);
 }

 void TFoo(T : T[])(T[] a) {
     pragma(msg, "T[]: " ~ T.stringof);
 }
I noticed that an automatically deduced TFoo call always yields the first, while TFoo!(uint[]) yields the array version if present, and defaults to the first elsewise. Am I incorrect in expecting the same behavior when (ab)using argument deduction or does my usage make sense? I tried searching for this combination (deduction & specialization) but couldn't find another forum post / documentation example.
I've always hated that aspect of specialization. I don't really understand why it's valid (how can T be T[]?) This works: void TFoo(T : U[], U)(T a) -Steve
Jan 17
parent reply Paul <paultjeadriaanse gmail.com> writes:
On Sunday, 17 January 2021 at 16:42:27 UTC, Steven Schveighoffer 
wrote:
 I've always hated that aspect of specialization. I don't really 
 understand why it's valid (how can T be T[]?)
I totally agree with that, that confuses me as well.
 This works:

 void TFoo(T : U[], U)(T a)
Oh cool, that's surprising to say the least. Thanks! This indeed works with argument deduction :)
Jan 17
parent Steven Schveighoffer <schveiguy gmail.com> writes:
On 1/17/21 3:41 PM, Paul wrote:
 On Sunday, 17 January 2021 at 16:42:27 UTC, Steven Schveighoffer wrote:
 This works:

 void TFoo(T : U[], U)(T a)
Oh cool, that's surprising to say the least. Thanks! This indeed works with argument deduction :)
It's basically saying if T matches the pattern U[] for some U (which is actually defined now inside the function), then it's a match (and preferred over the non-specialized template). -Steve
Jan 17
prev sibling parent Paul <paultjeadriaanse gmail.com> writes:
I just figured out half of my frustration is caused by a 
collision between the 'alias this'd template possibillity and the 
normal one.
For example:

 struct Bar(uint size, V) {
 	V[size] blup;
 	alias blup this;
 }
 
 void foo(S : T[], T)(S a) {
 	pragma(msg, "first");
 }
 
 void foo(S : Bar!(T, U), uint T, U)(S a) {
 	pragma(msg, "second");
 }
 Bar!(2, int) bar;
 foo(bar);
Will cause "called with argument types `(Bar!(2u, int))` matches both:DUB" (And "undefined identifier `T`DUB", "undefined identifier `U`DUB", but thats a false positive :/) While removal of either will make it work fine, as would removal of the alias. Templating:
 The template picked to instantiate is the one that is most 
 specialized that fits the types of the TemplateArgumentList.
Alias this:
 If an aggregate declaration defines an opCmp or opEquals 
 method, it will take precedence to that of the aliased this 
 member.
I was of the impression D only defaulted to the alias when the original implementation of a (member) function was missing / disfunctional. Shouldn't aliasing also follow this logic when using template specializations? (Even though it may not be a member function)
Jan 17