Edward Diener wrote:
Andrei Alexandrescu wrote:
Edward Diener wrote:
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> !
Actually it could be said that C++'s exercise with pointers to member
functions, which unifies a variety of functions (virtual, nonvirtual,
in a host of multiple inheritance scenario), although KISS-motivated
for the user, was at the same time a departure from C++'s usual
approach, and a disastrous one.
Why do you think pointer to member function was a "departure from C++'s
usual approach" ?
Don't pay for what you don't use, low-key approach to under-the-wraps
magic. The pointer to member type is the most elaborate of all C++
built-in types.
Bjarne mentioned in one of his books of having considered the C++
version of a delegate as a language construct ( taking the address of an
object's member function ) sometime in the design of C++ and having
rejected it. I can not remember the reason but it was evidently considered.
I'm not saying it was a decision made in ignorance. IMHO it was,
however, a wrong decision, and experience with pointer to member
functions (i.e., few even know how to write one down) supports that
hypothesis.
I don't think pointer to member function is a disaster, just sometimes
difficult to use, and of course very limiting. I agree I would have
still liked a delegate to be part of the C++ language instead of pointer
to member function, since the former is much more flexible. But
std::function/std::bind ( boost::function/boost::bind or boost::lambda )
solves that problem nicely at the expense of a little more syntax but
with great flexibility in binding.
"Nice" doesn't come to my mind when thinking of the above, but the
significant runtime cost does :o).
Andrei
