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.

Edward Diener wrote:
> 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.

To merge the two requires the generation of thunks at runtime to manipulate the parameters and calling convention. It's doable, but not simple.

Reply to Edward,

> 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.

The issue I see is that delegates are 64 bits (assuming a 32bit system) and functions are 32 bits. To maintain link compatibility with C, the 32bit plain-old-function-pointer form is needed. But it can't (cleanly) be used with delegates that need that extra 32bits for the context/this pointer.

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.
> 

Reply to Russell,

> what I did was just generate a template which automatically created a
> delegate out of it.
> 

somthing like this?

// IFTI might want somthing else\ here
R delegate(A) convert(R, A...)(R function(A) fnp)
{
 struct S
 {
     // "this" is a function pointer not a S*
    R do(A a) { U u; u.s = this; retrun s.f(a);}
 }

 union U
 {
    S* s;
    R function(a) f;
 }

 U u;
 u.f= fnp;
 retrun &u.s.do;
}

note it never news anything!

*Untested, but I've used the idea befor.*

Walter Bright wrote:
> Edward Diener wrote:
>> 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.
> 
> To merge the two requires the generation of thunks at runtime to manipulate the parameters and calling convention. It's doable, but not simple.

Perhaps allowing a delegate to point to a free function is enough to make people happy?

It sure would please me ;)

L.

Lionello Lunesu wrote:
> Walter Bright wrote:
>> To merge the two requires the generation of thunks at runtime to manipulate the parameters and calling convention. It's doable, but not simple.
> 
> Perhaps allowing a delegate to point to a free function is enough to make people happy?
> 
> It sure would please me ;)

Me too, but it still changes the calling convention, and still needs a thunk.

Walter Bright, el 28 de enero a las 18:51 me escribiste:
> Edward Diener wrote:
> >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.
> 
> To merge the two requires the generation of thunks at runtime to manipulate the parameters and calling convention. It's doable, but not simple.

And please, don't forget we need plain function pointers to interact with C.

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Todos en el mundo somos grasas, no hago distinción de sexo y raza, sólo que algunos lo disfrutan y otros no pueden evitarlo.

Yeah, I've seen people use the union magic to make it work without a new.  It's a cool trick, but it makes me squirm when I think about portability.  So I use a general version, using closures (note that my template uses a fixed "void" return code...previous posts in the NG can show you how to IFTI non-void return codes):

void delegate(TPL) convert(TPL...)(void function(TPL) func)
{
  return delegate void(TPL args)
         {
           func(args);
         };
}

// note that 'func' is put on the heap automatically by the closure
// mechanism in the compiler.

BCS wrote:
> Reply to Russell,
> 
>> what I did was just generate a template which automatically created a
>> delegate out of it.
>>
> 
> somthing like this?
> 
> // IFTI might want somthing else\ here
> R delegate(A) convert(R, A...)(R function(A) fnp)
> {
>  struct S
>  {
>      // "this" is a function pointer not a S*
>     R do(A a) { U u; u.s = this; retrun s.f(a);}
>  }
> 
>  union U
>  {
>     S* s;
>     R function(a) f;
>  }
> 
>  U u;
>  u.f= fnp;
>  retrun &u.s.do;
> }
> 
> note it never news anything!
> 
> *Untested, but I've used the idea befor.*
> 
> 

"Russell Lewis" <webmaster@villagersonline.com> wrote in message news:fnnivs$11k$1@digitalmars.com...
> Yeah, I've seen people use the union magic to make it work without a new. It's a cool trick, but it makes me squirm when I think about portability. So I use a general version, using closures (note that my template uses a fixed "void" return code...previous posts in the NG can show you how to IFTI non-void return codes):
>
> void delegate(TPL) convert(TPL...)(void function(TPL) func)
> {
>   return delegate void(TPL args)
>          {
>            func(args);
>          };
> }
>
> // note that 'func' is put on the heap automatically by the closure // mechanism in the compiler.

For those who aren't aware, this will only work in D2, not D1.  In D1 you'll probably get an access violation upon attempting to call the returned delegate.