How Nested Functions Work, part 1

[Andrei Alexandrescu]

Edward Diener wrote:
> Andrei Alexandrescu wrote:
>> Edward Diener wrote:
>>> Jarrett Billingsley wrote:
>>>> On Wed, Sep 2, 2009 at 9:45 AM, Andrei
>>>> Alexandrescu<SeeWebsiteForEmail at 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.

Andrei