Newbie initial comments on D language - delegate

[Russell Lewis]

I agree with the sentiment that it should be possible to implicitly cast 
a function to a delegate, but I don't think that merging the two is the 
best idea.

First, in my experience with D, I find that function pointers are rather 
rare.  As you get to use D more and more, you end up using delegate 
literals (or delegates to member functions) more and more, while 
pointers to ordinary functions become rare.  Sure, I just had to handle 
function pointers a few days ago, but that was noteworthy as the first 
time I had had to use them in a long time.  And what I did was just 
generate a template which automatically created a delegate out of it. :)

So, IMHO, having both doesn't add too much complexity to code, 
particularly if the implicit cast thing works some day.

The reason that I think that they should be retained (in addition to the 
C interop argument already posted) is that D aims to be a language that 
allows you to go down to the bare metal and write "C code in D."  If we 
had only delegates, and not function pointers, then we are hamstringing 
somebody who wants to write a bare-metal, fast-as-possible D program.

For me, with my toy programs, I'll keep using delegates for just about 
everything. :)

Edward Diener wrote:
> As I was reading about delegates and the syntax to initialize them I was
> thinking that such similar natural syntax had been suggested to C++ many
> times over the years. Of course delegates already have their antecedents
> in C++ Builder closures and .Net delegates among others. My reaction to
> delegates and their elegant syntax was "bravo, of course" but I also had
> the reaction of why are there both 'delegate' and 'function'.
> 
> Later in the pdf documentation I saw the a note that the future might
> see 'delegate' and 'function' folded into a single callable type. My
> reaction to this is: ABSOLUTELY NECESSARY. In fact I think it is a
> mistake to have divided callables into two types. The 'function' should
> have been dropped and a 'delegate' should have been initializable from
> any sort of callable in D, including class member function, class
> non-member functions ( static member functions ), global functions,
> nested functions, and any other callable in D I might have missed.
> 
> This is what C++ currently achieves through boost::function/boost::bind
> and it would be remarkable if D did not achieve the same sort of
> interoperability.
> 
> Making a delegate be able to represent any callable type of the given
> parameters/return-type enables any function-like object to be treated as
> a first-class language construct in D. Having two distinct callable
> types simply bifurcates the effectiveness of this concept. Needless to
> say, implementing callbacks, as well as events ( signals/slots ) having
> to deal with two different callable types whereas one would do nicely,
> is not the best design for a language. A callback in general does not
> care whether the handler is a member function, global function, or any
> other type of callable, it just makes the call and lets the callback
> handler ( "functor" if you will ) do what it wants with it.
> 
> Perhaps there are some implementation issues regarding this which I do
> not understand but these should be overcome in order to present a single
> interface to the callable concept. Perhaps this has been
> discussed ad nauseam on this NG already, so please correct me if I do
> not understand all the ramifications of uniting all callable types under
> the single idea of 'delegate' while perhaps keeping 'function' around
> merely for backward compatibility with old code until eventually it is
> dropped.
>