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

[d-bugmail at puremagic.com]

https://d.puremagic.com/issues/show_bug.cgi?id=11946



--- Comment #6 from Kenji Hara <k.hara.pg at gmail.com> 2014-01-22 21:52:01 PST ---
I change my argue to that this regression should be marked as invalid.

(In reply to comment #5)
> (In reply to comment #0)
> > ////////////////////////////////////////
> > static // http://d.puremagic.com/issues/show_bug.cgi?id=7805
> > int f(A...)() { return 0; }
> > 
> > struct S { int x; enum y = f!x(); }
> > ////////////////////////////////////////
> > 
> This should never have compiled. static should never have affected a template
> in global scope.

I also think so. But it had been worked because 'static' attribute is always
inherited to the instantiated function. I *fixed* the bug in the PR:

> > This used to compile, but it was broken by
> > https://github.com/D-Programming-Language/dmd/pull/2794

===

The main point of enhancment 11533 is that 'static template' should always
behave as same as module-level templates, regardless its declared position.

It's increasing consistency with currently known language concepts:
- 'static' attribute on module level declaration is just redundant
(meaningless).
- 'static' declaration inside aggregates/functions should behave as same as
module level declarations.
    * static member function is equivalent with free functions.
    * static local function is equivalent with free functions.

By the fix, `static int f(A...)(){ ... }` and `int f(A...)(){ ... }` have now
no difference at module level.
Therefore, instantiated f!(S.x) always requires hidden 'this' pointer on the
call.

To be more precise, current D language alias template parameter is not designed
just to take a symbol that is needed just only at compile-time.
If given template argument has implicit runtime context, compiler will _always_
try to take runtime context at the same time.
(To resolve the issue, "nested-ness interence" is sometimes proposed. But I'm
still not sure it is possible feature.)

To ignore the implicit automatic capturing, you need to write the idiom I
explained in comment#1.

As a conclusion: the reported breaking change is necessary due to add more
consistency to the language spec.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------