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