How Nested Functions Work, part 1

Edward Diener eddielee_no_spam_here at tropicsoft.com
Thu Sep 3 15:48:15 PDT 2009


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



More information about the Digitalmars-d mailing list