--- Comment #6 from Walter Bright <bugzi...@digitalmars.com> 2011-03-06
22:18:04 PST ---
(In reply to comment #4)
> First, the compiler should figure out that add does not need a frame pointer
> and consider it a static inner function, not a delegate.
Delegates and functions are different types. Deciding, based on the contents of
a function body, whether it is a function or a delegate makes for non-obvious
changes in type. Secondly, people are going to access outer variables from a
nested function, and will not expect it to break their code.
> Second, we need to agree that the reason you invoke is tied to the
> implementation - you use the same pointer for the class and for the hidden
> frame pointer, whereas of course there's no imposition to do so.
Making them use the same ABI means that they have the same type and are
interchangeable. This is a big deal. I don't think this will survive "a class
member function pointer is a different type than a nested function pointer".
> The hidden "this" parameter could go pretty much anywhere else.
> One way or another we must fix this. Oddly, a number of similar uses do work
> "by mistake", so at this moment we don't have a clear grasp on what
> distinguishes cases that work from cases that don't.
> We need to pursue this like a bloodhound and aggressively make as many cases
> possible work transparently. This is a major asset of D over virtually all
> other languages.
Consider if we add another type - a function pointer with two context pointers.
Now we have quite a menagerie:
1. function pointer
2. function pointer with context pointer (delegate)
3. function pointer with two context pointers
Is that really where we want to go?
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------