Thread overview
IFTI with value / template value parameter shadowing
Feb 23, 2014
Mathias LANG
Feb 23, 2014
Marc Schütz
Feb 24, 2014
Mathias LANG
February 23, 2014
Hi everyone,
I recently end up with the following code:

----
import std.stdio;

T IFTI_Type(T)(T value)       { return value; }

int IFTI_Value(int n)(int n)  { return n; }

int Shadowing_FTW(int n)()
{
   writeln(n);
   int n = 42;                     // Will print 6
   return n;
}


void    main()
{
    writeln(IFTI_Type(5));        // Will print 5
    writeln(Shadowing_FTW!6());   // Will print 42
    // This doesn't compile
    //writeln(IFTI_Value(5));
    writeln(IFTI_Value!5(8));     // Will print 8
}
----

This will print:
5
6
42
8

So from the commented call to IFTI_Value, I guessed that IFTI is not working for values. Is that intended behavior, or a bug ?
In addition it looks like template parameter are not considered while looking if a symbol with shadow another one. I didn't find anything on the bugtracker but (this)[https://d.puremagic.com/issues/show_bug.cgi?id=6980], but it's only related.
February 23, 2014
On Sunday, 23 February 2014 at 02:46:24 UTC, Mathias LANG wrote:
> int IFTI_Value(int n)(int n)  { return n; }
> ...
> So from the commented call to IFTI_Value, I guessed that IFTI is not working for values. Is that intended behavior, or a bug ?

There's no IFTI here. IFTI is about inferring a template argument (= type) from the type of a function argument. Your template argument is a value, not a type, so there's nothing to infer.

Not sure what you want to achieve. Do you want IFTI_Value(6) to be instantiated as IFTI_Value!6(6)? In this case, just leave the runtime parameter out:

int IFTI_Value(int n)() { return n; }

Of course, you will have to use the ! syntax then:

assert(IFTI_Value!6() == 6);

> In addition it looks like template parameter are not considered while looking if a symbol with shadow another one. I didn't find anything on the bugtracker but (this)[https://d.puremagic.com/issues/show_bug.cgi?id=6980], but it's only related.

I believe it works exactly as intended. The short form for template functions is just syntactic sugar for:

template IFTI_Value(int n) {
    int IFTI_Value(int n) { return n; }
}

This means that the function (runtime) parameter n is declared in the inner scope, and is thus expected to shadow the template parameter n in the outer scope.
February 24, 2014
On Sunday, 23 February 2014 at 11:49:26 UTC, Marc Schütz wrote:
> There's no IFTI here. IFTI is about inferring a template argument (= type) from the type of a function argument. Your template argument is a value, not a type, so there's nothing to infer.
>
There is the value. In IFTI_Type, the compiler understands that the 'T' in the parameter list is the same as the 'T' in the TemplateArgumentList.

For example this code compiles (from bug #4986):
-----
struct Foo(int n, int m) {
   void bar(int m2)(Foo!(m2, n) arg) {}
}

void main( )( ) {
   Foo!(3,2) f;
   Foo!(3,3) g;
   f.bar(g);
}
-----
So the compiler can deduce a value argument from a type, but not from a value known at compile time.


> Not sure what you want to achieve. Do you want IFTI_Value(6) to be instantiated as IFTI_Value!6(6)? In this case, just leave the runtime parameter out:

Yeah that works, and actually I agree that passing a value both in the parameters and template argument seems silly / odd at first sight. But there can be valid reasons to do so. I came accross this example while trying to shift a runtime argument to compile time while keeping source-level compatibility in a library.


>> In addition it looks like template parameter are not considered while looking if a symbol with shadow another one. I didn't find anything on the bugtracker but (this)[https://d.puremagic.com/issues/show_bug.cgi?id=6980], but it's only related.
>
> I believe it works exactly as intended. The short form for template functions is just syntactic sugar for:
>
> template IFTI_Value(int n) {
>     int IFTI_Value(int n) { return n; }
> }
>
> This means that the function (runtime) parameter n is declared in the inner scope, and is thus expected to shadow the template parameter n in the outer scope.

I have to give it a second read but IIRC the TDPL was pretty much saying that shadowing is not legal in D.