[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 #8 from Kenji Hara <k.hara.pg at gmail.com> 2014-01-22 23:41:23 PST ---
(In reply to comment #7)
> > It's increasing consistency with currently known language concepts:
> 
> Yes, this is all fine and well, but it does not justify making code that worked
> before now break with an indecipherable error message! The message "need 'this'
> to access member f" is an outright lie and is only good at showing a glaring
> compiler implementation problem.

There's no lie. The instantiated function _always_ needs valid runtime context,
*regardless* the context is really used or not inside function body.

Unfortunately current D has _no_ language feature to remove unused context
pointer (I call it "nested-ness inference").

> (In reply to comment #1)
> > template f(alias X)
> > {
> >     static string f()
> >     {
> >         //int x = X;
> >         return X.stringof; // OK
> >     }
> > }
> 
> This just shows another bug - that you still need "static" (which makes NO
> sense for a free function, templated or not), but now you must hide it inside a
> template!

It's not a bug. If the symbol X needs runtime context ('this' object or
function frame), f() will be instantiated like as member function or nested
function. To remove the implicit context pointer, 'static' will work.

---
After fixing issue 11533, these two declarations have different meanings.

template f(alias X) { static string f() { return null; } }  // A
static template f(alias X) { string f() { return null; } }  // B

In A, 'static' attribute is always added to the instantiated function 'f'. So
Even if X requires runtime context, 'f' still cannot access it.
In B, 'static' attribute is added _if_ X has no runtime context. If X needs
runtime context, instantiated 'f' also take the context to access valid runtime
storage of X.
---

> > 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.
> 
> So fix this first before breaking code?

It would be a not trivial language enhancement that still not yet designed.

> > To ignore the implicit automatic capturing, you need to write the idiom I
> > explained in comment#1.
> 
> If one needs to go to a bugtracker and learn of a hacky workaround (put a
> static function in a template) from a compiler developer to make their code
> compile, this is a terrible situation for D.

To explain the behavior, I'll update webside documentation and add a section in
release note. 

> > As a conclusion: the reported breaking change is necessary due to add more
> > consistency to the language spec.
> 
> I suggest that consistency bugs are fixed only after there is an immediate and
> obvious way to transition code that should not have compiled, to correct code
> which functions in the same way.

I already explained the way to do it in comment#1.

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