Functional programming in D and some reflexion on the () optionality.

[Mafi]

On Monday, 6 August 2012 at 18:29:38 UTC, deadalnix wrote:
> Le 06/08/2012 20:01, Mafi a écrit :
>> This comes from the 'real' function type is 'void f()' whose 
>> usage is
>> deprecated in D except for any function-/method-declaration:
>> Imagine a C-style declaration of the fuction type and you'll 
>> come to the
>> conclusion it's the way one defines functions in C/C++/D. But 
>> this type
>> has a big quirk: it's variable length because different 
>> fuctions with
>> the same signature can have a different amount of machine 
>> instuctions.
>
> Well, foo is either that either a function call. When it is 
> which is quite unclear.

Well, I'd say it's quite clear. It always does what's explicitly 
written. The only exception is when one tries to do something 
except calling or address-taking with a function (not a function 
pointer).

>
> No dereferencing is done in the compiled code anyway. BTW, an 
> « address of » operation is done on the type mentioned above.
>

I don't get what you are saying here. For me there's an inherent 
difference between a fuction and a function pointer. You 
shouldn't try to conflate them in a system language in my opinion.

>>
>> Maybe it is. But it comes from the fact that ufcs is an 
>> afterthought.
>>
>
> So we have already started to pill up feature that don't 
> integrate with each other C++ style.

I have to admit one could say this. But there's definitly a big 
difference between real members and ufcs which would be really 
hard to design around if one wants to stay in the C family.

>> I don't like authorative formal specs. It means most things 
>> are set in
>> stone and you have to write a new spec every once in a while 
>> which slows
>> down development of awesome language features.
>>
>
> This isn't about awesome language features. This is about 
> function calls ! The most basic feature ever.
>
> BTW, not stabilized feature shouldn't appear in what we call 
> stable release . . . They should be provided testing versions 
> of the compiler so they can be tortured and refined to the 
> point everything make sense.

This isn't about versioning schemes either! But there have been 
long discussions recently and at least some things will change 
with the development after 2.060 afaik.