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.
Therefore this can't be stored, passed or returned. You can't have array of them. The only exception is when you define a constant, then it's a funciton definition. Now because of this there is a need for another type equivalent to the function itself: its address. It's written 'void (*f)()' in C. This type is mostly reffered to as function even though it's only its address. Now D wants to go away from C declarations so the 'void function()' syntax was invented. Regardless of its name it's only the pointer to the actual functions even though D allows you to call it without dereferencing.
No dereferencing is done in the compiled code anyway. BTW, an « address of » operation is done on the type mentioned above.
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 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.
