[Issue 11946] "need 'this' to access member" when passing field to template parameter

[via Digitalmars-d-bugs]

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

timon.gehr at gmx.ch changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |timon.gehr at gmx.ch

--- Comment #44 from timon.gehr at gmx.ch ---
(In reply to Kenji Hara from comment #21)
> (In reply to comment #20)
> > (In reply to comment #19)
> > > Maybe you're misunderstanding the effect of 'static' attribute.
> > > As far as I know, it means that:
> > 
> > I think I understand how it works now. But I don't think this is how it SHOULD
> > work, because it is not intuitive. No other programming language does this, and
> > no one expects it to act like this. So I think it is a limitation imposed by
> > implementation detail that needs to be fixed.
> 
> I think it is enough reasonable definition because:
> 1. Currently dmd works that way.

That's basically diametrally opposed to how such things should be argued.

> 2. It is consistent definition and allow such the code in comment#1.
> ...

No, it is not a "consistent" definition, see below. Also, the code in comment#1
is ugly.

> Anyway, can you agree that the OP code needs fixup with 2.065 and this issue
> should me marked as INVALID?

I don't think this issue is invalid.

(In reply to Kenji Hara from comment #43)
> (In reply to Walter Bright from comment #41)
> > But D already has the notion of doing a "local instantiation" of a global
> > template, if an alias parameter is a local symbol - see hasNestedArgs().
> 
> Right, but if an instantiation is determined to "local instantiation",
> compiler cannot "unlocalize" it automatically.
> 
> ---
> To me current behavior is solid designed and more useful than old one.
> ...

I'm sorry, but the current behaviour is an ugly patchwork.
Even if there is value in explicit 'unlocalization' (which I am not convinced
of), introducing/moving around subtle and completely ad-hoc distinctions
barring any sound motivation like that is not going to fly. For one thing, what
if I want to make some members of my template scope static and not others?

class C{
    int x;
    template T(alias a){
        int foo(){ return x; }
        static int bar(int y){ return a(y); }
    }
}

Just because I don't want bar to be a member function of class C, with the new
behaviour I now _also_ disable local instantiation. What is this?

I also think that 'mangleof' shouldn't influence the design of this feature in
the slightest, forward references need an orthogonal and well-founded design
anyway.

--