www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Template type deduction and specialization

reply "Mike Parker" <aldacron gmail.com> writes:
I don't understand why this behaves as it does. Given the 
following two templates:

```
void printVal(T)(T t) {
	writeln(t);
}
void printVal(T : T*)(T* t) {
	writeln(*t);
}
```

I find that I actually have to explicitly instantiate the 
template with a pointer type to get the specialization.

```
void main() {
	int x = 100;
	printVal(x);
	int* px = &x;
	printVal(px);        // prints the address
         printVal!(int*)(px)  // prints 100
}
```

Intuitively, I would expect the specialization to be deduced 
without explicit instantiation. Assuming this isn't a bug (I've 
been unable to turn up anything in Bugzilla), could someone in 
the know explain the rationale behind this?
May 19 2015
next sibling parent reply "jklp" <jklp nowhere.fr> writes:
On Wednesday, 20 May 2015 at 06:31:13 UTC, Mike Parker wrote:
 I don't understand why this behaves as it does. Given the 
 following two templates:

 ```
 void printVal(T)(T t) {
 	writeln(t);
 }
 void printVal(T : T*)(T* t) {
 	writeln(*t);
 }
 ```

 I find that I actually have to explicitly instantiate the 
 template with a pointer type to get the specialization.

 ```
 void main() {
 	int x = 100;
 	printVal(x);
 	int* px = &x;
 	printVal(px);        // prints the address
         printVal!(int*)(px)  // prints 100
 }
 ```

 Intuitively, I would expect the specialization to be deduced 
 without explicit instantiation. Assuming this isn't a bug (I've 
 been unable to turn up anything in Bugzilla), could someone in 
 the know explain the rationale behind this?
--- import std.stdio; void printVal(T)(T t) { writeln(t); } void printVal(T: T)(T* t) { writeln(*t); } void main() { int x = 100; printVal(x); int* px = &x; printVal(px); } --- here it's selected correctly without explicit instantiation. But honestly i don't know why since the asterisk is removed from the T it looks quite incorrect.
May 20 2015
parent "Daniel Kozak" <kozzi11 gmail.com> writes:
On Wednesday, 20 May 2015 at 07:27:53 UTC, jklp wrote:
 ---
 import std.stdio;

 void printVal(T)(T t) {
 	writeln(t);
 }

 void printVal(T: T)(T* t) {
 	writeln(*t);
 }

 void main() {
 	int x = 100;
 	printVal(x);
 	int* px = &x;
 	printVal(px);
 }
 ---

 here it's selected correctly without explicit instantiation. 
 But honestly i don't know why since the  asterisk is removed 
 from the T it looks quite incorrect.
No it is correct it is same as: void printVal(T: int)(T* t) { writeln(*t); }
May 20 2015
prev sibling next sibling parent reply "Namespace" <rswhite4 gmail.com> writes:
On Wednesday, 20 May 2015 at 06:31:13 UTC, Mike Parker wrote:
 I don't understand why this behaves as it does. Given the 
 following two templates:

 ```
 void printVal(T)(T t) {
 	writeln(t);
 }
 void printVal(T : T*)(T* t) {
 	writeln(*t);
 }
 ```

 I find that I actually have to explicitly instantiate the 
 template with a pointer type to get the specialization.

 ```
 void main() {
 	int x = 100;
 	printVal(x);
 	int* px = &x;
 	printVal(px);        // prints the address
         printVal!(int*)(px)  // prints 100
 }
 ```

 Intuitively, I would expect the specialization to be deduced 
 without explicit instantiation. Assuming this isn't a bug (I've 
 been unable to turn up anything in Bugzilla), could someone in 
 the know explain the rationale behind this?
What about: ---- import std.stdio; void printVal(T)(T t) { static if (is(T : U*, U)) printVal(*t); else writeln(t); } void main() { int x = 100; printVal(x); int* px = &x; printVal(px); } ----
May 20 2015
next sibling parent Mike Parker <aldacron gmail.com> writes:
On 5/20/2015 4:36 PM, Namespace wrote:

 What about:
 ----
 import std.stdio;

 void printVal(T)(T t) {
      static if (is(T : U*, U))
          printVal(*t);
      else
          writeln(t);
 }
Thanks, but I'm not looking for alternatives. I'm trying to figure out why it doesn't work as expected.
May 20 2015
prev sibling parent Jonathan M Davis via Digitalmars-d-learn writes:
On Wednesday, May 20, 2015 07:36:21 Namespace via Digitalmars-d-learn wrote:
 What about:
 ----
 import std.stdio;

 void printVal(T)(T t) {
      static if (is(T : U*, U))
          printVal(*t);
      else
          writeln(t);
 }

 void main() {
      int x = 100;
      printVal(x);
      int* px = &x;
      printVal(px);
 }
 ----
That mostly works, but you it runs the classic risk of running into problems with alias this (which is why checking for implicit conversions in static if or template constraints is so incredibly dangerous if you're not _very_ careful). std.traits defines isPointer as follows: enum bool isPointer(T) = is(T == U*, U) && !isAggregateType!T; which avoids the alias this problem. Regardless, it's more idiomatic to just use isPointer. - Jonathan M Davis
May 20 2015
prev sibling next sibling parent reply Daniel =?UTF-8?B?S296w6Fr?= via Digitalmars-d-learn writes:
On Wed, 20 May 2015 06:31:11 +0000
Mike Parker via Digitalmars-d-learn <digitalmars-d-learn puremagic.com>
wrote:

 I don't understand why this behaves as it does. Given the 
 following two templates:
 
 ```
 void printVal(T)(T t) {
 	writeln(t);
 }
 void printVal(T : T*)(T* t) {
 	writeln(*t);
 }
 ```
 
 I find that I actually have to explicitly instantiate the 
 template with a pointer type to get the specialization.
 
 ```
 void main() {
 	int x = 100;
 	printVal(x);
 	int* px = &x;
 	printVal(px);        // prints the address
          printVal!(int*)(px)  // prints 100
 }
 ```
 
 Intuitively, I would expect the specialization to be deduced 
 without explicit instantiation. Assuming this isn't a bug (I've 
 been unable to turn up anything in Bugzilla), could someone in 
 the know explain the rationale behind this?
Because it cannot deduce type T: try this: void printVal(T : T*)(T* t) { writeln(*t); } void main() { int x = 100; int* px = &x; printVal(px); } It will print error. My advise is not to use T:T* or T:T[] it works only when explicitly instantiate. Is better use T:M*,M or T:M[], M because it works automaticly and you have both types available. import std.stdio; void printVal(T)(T t) { writeln(t); } void printVal(T:M*,M)(T t) { writeln(*t); } void main() { int x = 100; printVal(x); int* px = &x; printVal(px); // prints the 100 }
May 20 2015
parent reply "Daniel Kozak" <kozzi11 gmail.com> writes:
On Wednesday, 20 May 2015 at 09:24:28 UTC, Daniel Kozák wrote:
 On Wed, 20 May 2015 06:31:11 +0000
 Mike Parker via Digitalmars-d-learn 
 <digitalmars-d-learn puremagic.com>
 wrote:

 I don't understand why this behaves as it does. Given the 
 following two templates:
 
 ```
 void printVal(T)(T t) {
 	writeln(t);
 }
 void printVal(T : T*)(T* t) {
 	writeln(*t);
 }
 ```
 
 I find that I actually have to explicitly instantiate the 
 template with a pointer type to get the specialization.
 
 ```
 void main() {
 	int x = 100;
 	printVal(x);
 	int* px = &x;
 	printVal(px);        // prints the address
          printVal!(int*)(px)  // prints 100
 }
 ```
 
 Intuitively, I would expect the specialization to be deduced 
 without explicit instantiation. Assuming this isn't a bug 
 (I've been unable to turn up anything in Bugzilla), could 
 someone in the know explain the rationale behind this?
Because it cannot deduce type T: try this: void printVal(T : T*)(T* t) { writeln(*t); } void main() { int x = 100; int* px = &x; printVal(px); } It will print error. My advise is not to use T:T* or T:T[] it works only when explicitly instantiate. Is better use T:M*,M or T:M[], M because it works automaticly and you have both types available. import std.stdio; void printVal(T)(T t) { writeln(t); } void printVal(T:M*,M)(T t) { writeln(*t); } void main() { int x = 100; printVal(x); int* px = &x; printVal(px); // prints the 100 }
DOCS: http://dlang.org/template.html#function-templates says: Function template type parameters that are to be implicitly deduced may not have specializations:
May 20 2015
next sibling parent Mike Parker <aldacron gmail.com> writes:
On 5/20/2015 6:35 PM, Daniel Kozak wrote:

 DOCS: http://dlang.org/template.html#function-templates
 says: Function template type parameters that are to be implicitly
 deduced may not have specializations:
Thanks. For the record, the example there is the exact same case. void Foo(T : T*)(T t) { ... } int x,y; Foo!(int*)(x); // ok, T is not deduced from function argument Foo(&y); // error, T has specialization I was looking for the answer in higher up the page in the Specializations section under Argument Deduction. Didn't think to look for it under Function Templates.
May 20 2015
prev sibling parent reply "Mike Parker" <aldacron gmail.com> writes:
On Wednesday, 20 May 2015 at 09:35:43 UTC, Daniel Kozak wrote:

 DOCS: http://dlang.org/template.html#function-templates
 says: Function template type parameters that are to be 
 implicitly deduced may not have specializations:
OK, having reread this, I'm not clear at all what's going on. Here, I'm instantiating the templates such that the types are implicitly deduced from the function arguments and they pick up the specializations just fine. ``` T sum(T : ulong)(T lhs, T rhs) { writeln("Integrals"); return cast(T)(lhs + rhs); } T sum(T : real)(T lhs, T rhs) { writeln("Floating Point"); import std.math : round; return round(lhs + rhs); } void main() { writeln(sum(10L, 20L)); writeln(sum(10.11, 3.22)); } ``` If the documentation is correct, then this shouldn't work, but it does. It breaks only when specializing on pointers and arrays, in which case I have to implicitly instantiate.
May 20 2015
parent reply Daniel =?UTF-8?B?S296w6Fr?= via Digitalmars-d-learn writes:
DOC say  `may not have` not `must not have` ;-)

On Wed, 20 May 2015 13:24:22 +0000
Mike Parker via Digitalmars-d-learn <digitalmars-d-learn puremagic.com>
wrote:

 On Wednesday, 20 May 2015 at 09:35:43 UTC, Daniel Kozak wrote:
 
 DOCS: http://dlang.org/template.html#function-templates
 says: Function template type parameters that are to be 
 implicitly deduced may not have specializations:
OK, having reread this, I'm not clear at all what's going on. Here, I'm instantiating the templates such that the types are implicitly deduced from the function arguments and they pick up the specializations just fine. ``` T sum(T : ulong)(T lhs, T rhs) { writeln("Integrals"); return cast(T)(lhs + rhs); } T sum(T : real)(T lhs, T rhs) { writeln("Floating Point"); import std.math : round; return round(lhs + rhs); } void main() { writeln(sum(10L, 20L)); writeln(sum(10.11, 3.22)); } ``` If the documentation is correct, then this shouldn't work, but it does. It breaks only when specializing on pointers and arrays, in which case I have to implicitly instantiate.
May 20 2015
parent reply "Mike Parker" <aldacron gmail.com> writes:
On Wednesday, 20 May 2015 at 13:46:22 UTC, Daniel Kozák wrote:
 DOC say  `may not have` not `must not have` ;-)
OK, if that's the intent, it needs to be reworded. As it stands, it looks more like it's saying specialization is not permissible, rather than what "might" be possible. As in: "Employees may not bring unauthorized individuals into the work space." It's very rare to use "must not" when denying permission.
May 20 2015
parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 05/20/2015 04:10 PM, Mike Parker wrote:
 On Wednesday, 20 May 2015 at 13:46:22 UTC, Daniel Kozák wrote:
 DOC say  `may not have` not `must not have` ;-)
OK, if that's the intent, it needs to be reworded. As it stands, it looks more like it's saying specialization is not permissible, rather than what "might" be possible.
That's the only meaning that I get: The doc means "must not". Yet, as you've shown, the behavior does not match the doc. Ali
May 20 2015
parent reply Daniel =?UTF-8?B?S296w6Fr?= via Digitalmars-d-learn writes:
On Wed, 20 May 2015 17:23:05 -0700
Ali Çehreli via Digitalmars-d-learn <digitalmars-d-learn puremagic.com>
wrote:

 On 05/20/2015 04:10 PM, Mike Parker wrote:
 On Wednesday, 20 May 2015 at 13:46:22 UTC, Daniel Kozák wrote:
 DOC say  `may not have` not `must not have` ;-)
OK, if that's the intent, it needs to be reworded. As it stands, it looks more like it's saying specialization is not permissible, rather than what "might" be possible.
That's the only meaning that I get: The doc means "must not". Yet, as you've shown, the behavior does not match the doc. Ali
1.) we could fix just doc - easiest, but inconsistent 2.) remove implicit deduction even for fun(T:char)(T c) and all other specialization - code breakage so imho not good 3.) fix doc and allow even fun(T:T*)(T* p) - same as 2
May 20 2015
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 5/21/15 2:35 AM, Daniel Kozák via Digitalmars-d-learn wrote:
 On Wed, 20 May 2015 17:23:05 -0700
 Ali Çehreli via Digitalmars-d-learn <digitalmars-d-learn puremagic.com>
 wrote:

 On 05/20/2015 04:10 PM, Mike Parker wrote:
 On Wednesday, 20 May 2015 at 13:46:22 UTC, Daniel Kozák wrote:
 DOC say  `may not have` not `must not have` ;-)
OK, if that's the intent, it needs to be reworded. As it stands, it looks more like it's saying specialization is not permissible, rather than what "might" be possible.
That's the only meaning that I get: The doc means "must not". Yet, as you've shown, the behavior does not match the doc. Ali
1.) we could fix just doc - easiest, but inconsistent
Before doing this, we have to understand what works and what doesn't. It's not clear to me.
 2.) remove implicit deduction even for fun(T:char)(T c) and all other
 specialization - code breakage so imho not good
I don't think this is possible, this would break lots of existing code.
 3.) fix doc and allow even fun(T:T*)(T* p) - same as 2
I agree with this fix. I don't understand why specialization should disqualify IFTI. Can someone explain this rationale besides "because the docs say so"? A possible explanation is that the specialization doesn't resolve to a *specific type* but instead resolves to a *flavor of type*. For example, does this work? foo(T : int*)(T t) That would make some sense at least, but I don't understand why this rule is in place. -Steve
May 21 2015
parent reply Daniel =?UTF-8?B?S296w6Fr?= via Digitalmars-d-learn writes:
On Thu, 21 May 2015 08:54:54 -0400
Steven Schveighoffer via Digitalmars-d-learn
<digitalmars-d-learn puremagic.com> wrote:

 On 5/21/15 2:35 AM, Daniel Kozák via Digitalmars-d-learn wrote:
 On Wed, 20 May 2015 17:23:05 -0700
 Ali Çehreli via Digitalmars-d-learn
 <digitalmars-d-learn puremagic.com> wrote:

 On 05/20/2015 04:10 PM, Mike Parker wrote:
 On Wednesday, 20 May 2015 at 13:46:22 UTC, Daniel Kozák wrote:
 DOC say  `may not have` not `must not have` ;-)
OK, if that's the intent, it needs to be reworded. As it stands, it looks more like it's saying specialization is not permissible, rather than what "might" be possible.
That's the only meaning that I get: The doc means "must not". Yet, as you've shown, the behavior does not match the doc. Ali
1.) we could fix just doc - easiest, but inconsistent
Before doing this, we have to understand what works and what doesn't. It's not clear to me.
 2.) remove implicit deduction even for fun(T:char)(T c) and all
 other specialization - code breakage so imho not good
I don't think this is possible, this would break lots of existing code.
 3.) fix doc and allow even fun(T:T*)(T* p) - same as 2
I agree with this fix. I don't understand why specialization should disqualify IFTI. Can someone explain this rationale besides "because the docs say so"?
But this will break more code than 2. So it is impossible to fix it.
May 21 2015
parent reply "Daniel Kozak" <kozzi11 gmail.com> writes:
On Thursday, 21 May 2015 at 13:12:36 UTC, Daniel Kozák wrote:
 On Thu, 21 May 2015 08:54:54 -0400
 Steven Schveighoffer via Digitalmars-d-learn
 <digitalmars-d-learn puremagic.com> wrote:

 On 5/21/15 2:35 AM, Daniel Kozák via Digitalmars-d-learn wrote:
 On Wed, 20 May 2015 17:23:05 -0700
 Ali Çehreli via Digitalmars-d-learn
 <digitalmars-d-learn puremagic.com> wrote:

 On 05/20/2015 04:10 PM, Mike Parker wrote:
 On Wednesday, 20 May 2015 at 13:46:22 UTC, Daniel Kozák 
 wrote:
 DOC say  `may not have` not `must not have` ;-)
OK, if that's the intent, it needs to be reworded. As it stands, it looks more like it's saying specialization is not permissible, rather than what "might" be possible.
That's the only meaning that I get: The doc means "must not". Yet, as you've shown, the behavior does not match the doc. Ali
1.) we could fix just doc - easiest, but inconsistent
Before doing this, we have to understand what works and what doesn't. It's not clear to me.
 2.) remove implicit deduction even for fun(T:char)(T c) and 
 all
 other specialization - code breakage so imho not good
I don't think this is possible, this would break lots of existing code.
 3.) fix doc and allow even fun(T:T*)(T* p) - same as 2
I agree with this fix. I don't understand why specialization should disqualify IFTI. Can someone explain this rationale besides "because the docs say so"?
But this will break more code than 2. So it is impossible to fix it.
Not more, but it will be worst, because it could change behaviour of program without error message
May 21 2015
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 5/21/15 9:14 AM, Daniel Kozak wrote:
 On Thursday, 21 May 2015 at 13:12:36 UTC, Daniel Kozák wrote:
 On Thu, 21 May 2015 08:54:54 -0400
 Steven Schveighoffer via Digitalmars-d-learn
 <digitalmars-d-learn puremagic.com> wrote:

 On 5/21/15 2:35 AM, Daniel Kozák via Digitalmars-d-learn wrote:
 On Wed, 20 May 2015 17:23:05 -0700
 Ali Çehreli via Digitalmars-d-learn
 <digitalmars-d-learn puremagic.com> wrote:

 On 05/20/2015 04:10 PM, Mike Parker wrote:
 On Wednesday, 20 May 2015 at 13:46:22 UTC, Daniel Kozák >>> wrote:
 DOC say  `may not have` not `must not have` ;-)
OK, if that's the intent, it needs to be reworded. As it >>> stands, it looks more like it's saying specialization is not >>>
permissible,
 rather than what "might" be possible.
That's the only meaning that I get: The doc means "must >> not". Yet, as you've shown, the behavior does not match the doc. Ali
1.) we could fix just doc - easiest, but inconsistent
Before doing this, we have to understand what works and what doesn't. It's not clear to me.
 2.) remove implicit deduction even for fun(T:char)(T c) and > all
 other specialization - code breakage so imho not good
I don't think this is possible, this would break lots of existing code.
 3.) fix doc and allow even fun(T:T*)(T* p) - same as 2
I agree with this fix. I don't understand why specialization should disqualify IFTI. Can someone explain this rationale besides "because the docs say so"?
But this will break more code than 2. So it is impossible to fix it.
Not more, but it will be worst, because it could change behaviour of program without error message
How so? My understanding is that it's illegal to call a function with specializations when IFTI is involved. This means code that currently doesn't compile, will compile. But what working code base has non-compiling code? I guess some __traits(compiles) calls would change, but I don't see the harm in this? You can call the function with an explicit instantiation, calling it with an implicit one isn't going to change the semantic meaning of the call. In other words, code that does this: foo(x); that doesn't compile, will start to compile as if you did: foo!(typeof(x))(x). How does this break code? And how does it break more code than 2? -Steve
May 21 2015
parent reply Daniel =?UTF-8?B?S296w6Fr?= via Digitalmars-d-learn writes:
On Thu, 21 May 2015 09:58:16 -0400
Steven Schveighoffer via Digitalmars-d-learn
<digitalmars-d-learn puremagic.com> wrote:

 On 5/21/15 9:14 AM, Daniel Kozak wrote:
 On Thursday, 21 May 2015 at 13:12:36 UTC, Daniel Kozák wrote:
 On Thu, 21 May 2015 08:54:54 -0400
 Steven Schveighoffer via Digitalmars-d-learn
 <digitalmars-d-learn puremagic.com> wrote:

 On 5/21/15 2:35 AM, Daniel Kozák via Digitalmars-d-learn wrote:
 On Wed, 20 May 2015 17:23:05 -0700
 Ali Çehreli via Digitalmars-d-learn
 <digitalmars-d-learn puremagic.com> wrote:

 On 05/20/2015 04:10 PM, Mike Parker wrote:
 On Wednesday, 20 May 2015 at 13:46:22 UTC, Daniel Kozák >>>
 wrote:
 DOC say  `may not have` not `must not have` ;-)
OK, if that's the intent, it needs to be reworded. As it >>> stands, it looks more like it's saying specialization is not

permissible,
 rather than what "might" be possible.
That's the only meaning that I get: The doc means "must >> not". Yet, as you've shown, the behavior does not match the doc. Ali
1.) we could fix just doc - easiest, but inconsistent
Before doing this, we have to understand what works and what doesn't. It's not clear to me.
 2.) remove implicit deduction even for fun(T:char)(T c) and >
 all other specialization - code breakage so imho not good
I don't think this is possible, this would break lots of existing code.
 3.) fix doc and allow even fun(T:T*)(T* p) - same as 2
I agree with this fix. I don't understand why specialization should disqualify IFTI. Can someone explain this rationale besides "because the docs say so"?
But this will break more code than 2. So it is impossible to fix it.
Not more, but it will be worst, because it could change behaviour of program without error message
How so? My understanding is that it's illegal to call a function with specializations when IFTI is involved. This means code that currently doesn't compile, will compile. But what working code base has non-compiling code? I guess some __traits(compiles) calls would change, but I don't see the harm in this? You can call the function with an explicit instantiation, calling it with an implicit one isn't going to change the semantic meaning of the call. In other words, code that does this: foo(x); that doesn't compile, will start to compile as if you did: foo!(typeof(x))(x). How does this break code? And how does it break more code than 2? -Steve
import std.stdio; void f(T:T*)(T* t) { writeln("before change this is not called"); } void f(T)(T t) { writeln("before change this is called"); } void main() { int val; f(&val); f!(int*)(&val); } now it prints: before change this is called before change this is not called but if we make change as you suggest this will be print: before change this is not called before change this is not called
May 21 2015
parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 5/21/15 10:15 AM, Daniel Kozák via Digitalmars-d-learn wrote:

 import std.stdio;

 void f(T:T*)(T* t)
 {
      writeln("before change this is not called");
 }

 void f(T)(T t)
 {
      writeln("before change this is called");
 }


 void main() {
      int val;
      f(&val);
      f!(int*)(&val);
 }

 now it prints:
 before change this is called
 before change this is not called

 but if we make change as you suggest this will be print:

 before change this is not called
 before change this is not called
Ugh, that was not what my reading of the docs seemed to suggest: "Function template type parameters that are to be implicitly deduced may not have specializations" I misread that to mean *templates* that have specializations cannot be used for IFTI. Now I see that the rule is talking not about templates but *template type parameters*. But the more I look at this, the more I think this is a bad code smell. I can't see any logical reason to do something different with an implicit deduction vs. an explicit call. Especially in the face of other code that Can anyone come up a valid use case for this? Even one that is a hack? I'll note that if you replace the specialization with: f(T : int *)(T t) it calls the specialized version twice. Clearly, the rule is not properly described or not properly implemented. I would like to hear from Walter on this, what are the thoughts behind this rule? -Steve
May 21 2015
prev sibling parent reply Jonathan M Davis via Digitalmars-d-learn writes:
On Wednesday, May 20, 2015 06:31:11 Mike Parker via Digitalmars-d-learn wrote:
 I don't understand why this behaves as it does. Given the
 following two templates:

 ```
 void printVal(T)(T t) {
   writeln(t);
 }
 void printVal(T : T*)(T* t) {
   writeln(*t);
 }
 ```

 I find that I actually have to explicitly instantiate the
 template with a pointer type to get the specialization.

 ```
 void main() {
   int x = 100;
   printVal(x);
   int* px = &x;
   printVal(px);        // prints the address
          printVal!(int*)(px)  // prints 100
 }
 ```

 Intuitively, I would expect the specialization to be deduced
 without explicit instantiation. Assuming this isn't a bug (I've
 been unable to turn up anything in Bugzilla), could someone in
 the know explain the rationale behind this?
Well, if printVal!(int*)(px); prints 100, then that's a bug. It should print the address. In fact, it should be _impossible_ for the second overload of printVal to ever be instantiated. Think about it. What does T : T* mean? It means that T is implicitly convertible to T*. And when is a type ever implicitly convertible to a pointer to itself? int x = 100; int y = &x; isn't going to compile, so neither should that second overload ever end up being used. Use std.traits.isPointer if you want to test for whether a type is a pointer or not. I'm using a fairly recent version of dmd master, and it prints out the address for px in both cases when I compile your code. So, if it's printing out 100 for you on the second call, it would appear to be a bug that has been fixed at some point since 2.067 (or whatever version you're using) was released. - Jonathan M Davis
May 20 2015
next sibling parent "Daniel Kozak" <kozzi11 gmail.com> writes:
On Wednesday, 20 May 2015 at 09:35:48 UTC, Jonathan M Davis wrote:
 Well, if

 printVal!(int*)(px);

 prints 100, then that's a bug. It should print the address. In 
 fact, it
 should be _impossible_ for the second overload of printVal to 
 ever be
 instantiated
IMHO thats not true, it should print 100. This is what spec say. void printVal(T : T*)(T* t) { writeln(*t); } T is deduce to be int so we have void printVal(int* t) { writeln(*t); } which will print value not address
May 20 2015
prev sibling parent reply Mike Parker <aldacron gmail.com> writes:
On 5/20/2015 6:35 PM, Jonathan M Davis via Digitalmars-d-learn wrote:

 I'm using a fairly recent version of dmd master, and it prints out the
 address for px in both cases when I compile your code. So, if it's printing
 out 100 for you on the second call, it would appear to be a bug that has
 been fixed at some point since 2.067 (or whatever version you're using) was
 released.

 - Jonathan M Davis
I'm using 2.067.0, but according to the section of the docs Daniel pointer me to[1], printing 100 is the correct behavior in the second call. [1] http://dlang.org/template.html#function-templates
May 20 2015
parent Jonathan M Davis via Digitalmars-d-learn writes:
On Wednesday, May 20, 2015 19:20:19 Mike Parker via Digitalmars-d-learn wrote:
 On 5/20/2015 6:35 PM, Jonathan M Davis via Digitalmars-d-learn wrote:

 I'm using a fairly recent version of dmd master, and it prints out the
 address for px in both cases when I compile your code. So, if it's printing
 out 100 for you on the second call, it would appear to be a bug that has
 been fixed at some point since 2.067 (or whatever version you're using) was
 released.

 - Jonathan M Davis
I'm using 2.067.0, but according to the section of the docs Daniel pointer me to[1], printing 100 is the correct behavior in the second call. [1] http://dlang.org/template.html#function-templates
Hmmm. It looks like when : is used directly in the template parameter list, it doesn't mean the same thing as when it's used in an is expression. I _never_ use : directly in the template parameter list, so I misunderstood what it did. And looking over what it says, your printVal(T : T*) should be used when explicitly calling printVal!(int*) but that printVal(px) will print the address, because for whatever reason, IFTI doesn't work with the : syntax directly in the template parameter list (I have no idea why, but that section in the spec is pretty clear about that). So, the fact that it's printing the address for me in both cases is bug. But if you're seeing it print 100 for printVal!(int*)(px) and the address for printVal(px), then that would be correct per the spec. Personally, I wish that template specializations like this just didn't exist in the language, because they're redundant with template constraints and just add more complication to the language, but it's not like we're going to get rid of them at this point, unfortunately. But because I think that they're pointless, I never use them, and clearly am not familiar enough with how they work. - Jonathan M Davis
May 20 2015