http://d.puremagic.com/issues/show_bug.cgi?id=5710



--- 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 
> as
> 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: -------

Reply via email to