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

[deadalnix]

Le 06/08/2012 21:07, Mafi a écrit :
>> 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.
>

On any hardware, a function call will boil down to set up stuff on the 
stack and branching, jumping, calling or whatever on the ADDRESS of the 
function's code.

In other term, what is generated always involve the function's 
instruction address. If you dereference that address, you get 
instructions, but that hardly something useful to have at higher levels 
because you can"t do anything with it anyway.

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

Well D also advertise itself as OO and functional. Obviously, decision 
will have to be made. Because if no design decision is made, you ends up 
like it is now : micro decision are made when coding, and no overall is 
followed.

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

Yes, that was a digression. When stating that UFCS don't integrate 
nicely with other features, this showed the need for incubation of 
feature, and as recent discussions have been made on versioning, I made 
a bridge.