How Nested Functions Work, part 1

[Andrei Alexandrescu]

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

Don't pay for what you don't use, low-key approach to under-the-wraps 
magic. The pointer to member type is the most elaborate of all C++ 
built-in types.

> 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'm not saying it was a decision made in ignorance. IMHO it was, 
however, a wrong decision, and experience with pointer to member 
functions (i.e., few even know how to write one down) supports that 
hypothesis.

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

"Nice" doesn't come to my mind when thinking of the above, but the 
significant runtime cost does :o).


Andrei