How Nested Functions Work, part 1

[Edward Diener]

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

Why do you think pointer to member function was a "departure from C++'s 
usual approach" ?

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