Andrei Alexandrescu wrote:
Edward Diener wrote:
Jarrett Billingsley wrote:
On Wed, Sep 2, 2009 at 9:45 AM, Andrei
Alexandrescu<seewebsiteforem...@erdani.org> wrote:
Jarrett Billingsley wrote:
Well repeat should probably always take a delegate since most likely,
you're going to be passing it a lambda. However I agree that it would
be very, very nice to be able to make APIs take just delegates and
allow functions to be implicitly cast to them. You can already make
your own thunks, but they're not going to be as efficient as something
that actually works on an ABI level.
Did someone file a bug report on this?
Surprisingly, it doesn't seem like it. Walter himself, in the spec,
said that "Function pointers and delegates may merge into a common
syntax and be interchangeable with each other," so I just assume that
no one has found it necessary to make a report. Maybe there should be.
I suggested this a long time back on this NG, and I am sure many
others have also. A function pointer should essentially be a delegate
whose object is null. That is essentially the way delegates are in
.Net. In C++, boost::Function can encompass any C++ callable type so
there is little theoretical reason why D should not encompass all
callable types into a delegate. Having to program for any callable
type, in a functional callable or signal/slots library, by dealing
with the two signature variations of a function pointer and a delegate
rather than a single common signature is a real PITA in an advanced
programming language.
IMHO it's ok if there are two types, as long as function is implicitly
convertible to delegate. Function pointers have the advantage that they
are only one word in size, can be assigned to atomically, and help
interfacing with C callback APIs.
Good point ! That would be fine also. The basic issue is to allow a
single syntactical construct to encompass all callables in order to
simplify code design.
But I am still theoretically in favor of the single type, purely from
KISS principles. The single delegate type subsumes the function pointer
type. As far as the size savings, of course some small amount of memory
can be saved. As far as the assigned speed, if the delegate type in D is
as I suppose a language, and not a library, implementation, the language
( compiler ) can be smart enough to know that the programmer is
assigning a function pointer to the delegate and make the speedier
atomic assignment.
What I imagine will happen in D is that when an updated delegate type
allows itself to be initialized with a function pointer, the vast
majority of D programmers will use delegate for all callables and the
function pointer will remain simply an artefact of the language. Then D
can eventually get rid of it <g> !
This is analogous to the transition that will happen in C++ from
function pointers/member function pointers to std::function in C++0x. Of
course I never expect C++ to get rid of anything because some person in
3009, going back to code 100 years old and still supported by C++30x,
still uses function pointers/member function pointers and the C++
standard committee deems it impermissible to break that code <g><g> !