https://d.puremagic.com/issues/show_bug.cgi?id=11946
--- Comment #6 from Kenji Hara <k.hara...@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: -------
