How Nested Functions Work, part 1

[Don]

Andrei Alexandrescu wrote:
> 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.

No kidding. When writing my "Member function pointers" CodeProject 
article [1], it seemed that nobody had truly documented the extent of 
their grotesqueness before. And during the course of writing that 
article, I noticed that the compiler vendor with the sanest 
implementation also had an alternative language called D...

[1] http://www.codeproject.com/KB/cpp/FastDelegate.aspx

BTW: I've just discovered that my article is referenced from the C++ 
FQA, with a prominent note: "WARNING: this stuff can be used to scare 
little children."
<g>