On Monday, 6 August 2012 at 19:45:17 UTC, deadalnix wrote:
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.


It's the same with an int on the stack, isn't it (literally on the stack; not optimized into a register). To access it, one has to dereference its address but you wouldn't like conflating int and int*. The difference is between the address being a constant (maybe relative to the stack) and being totally unknown. In my opinion this is a big difference, also for functions.

...

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.


Reply via email to