On 28 August 2012 16:50, Daniel Murphy
<yebblies@nospamgmail.com> wrote:
"Jonathan M Davis" <jmdavisProg@gmx.com> wrote in message
news:mailman.1446.1346070222.31962.digitalmars-d@puremagic.com...
>
> Default arguments just do not make sense with function pointers, because
> they
> don't follow the function pointer, because it's a _pointer_ and has no
> knowledge of what it's pointing to. It's only at the declaration point of
> the
> function that the default argument exists, and that has _nothing_ to do
> with
> the function pointer. You might as well ask a reference of type Object
> what
> the arguments used to construct the derived class that it actually refers
> to
> were as expect a function pointer to have any clue about default arguments
> to
> the function that it points to.
>
> - Jonathan M Davis
Yes, this. I looked into fixing issue 3866 earlier this year, and Kenji's
list sounds very familiar.
It comes down to - function pointers are not function declarations and
therefore can't do everything function declarations do, such as overloading
and default arguments. This is the price of being able to reassign them.
Yes it is possible to make them work the way Manu has been using them, but
the solution is messy and I seriously doubt it's worth it. I agree with
everything Andrei has said about this.
I don't consider putting default arguments back in the type a valid approach
because of the reason above, so that leaves giving function pointer
variables the ability to have default arguments. This seems to me like a
really dumb corner case with the same problems.
Well that's painful for a number of reasons.
Other than the fact that I need to rewrite a bunch of code, I can't actually produce a solution that works as well in lieu of some feature requests.
A language feature should be deprecated for some time before it is surprise-removed like that... that would allow some time to discuss and possibly implement support for work-arounds.
Since I'll need to create wrapper functions and stubs for everything, I really need __forceinline, or debug builds will really suffer. (That said, I need it anyway for heaps of other stuff (SIMD in particular), but this really seals the deal.)
Without it, all function calls require call-through stubs, all my API calls become double-calls, and debugging becomes really tedious (stepping into and out of stubs generated by magic that don't really exist every time you press F11 >_<).
Also, in my case, I really need to be able to forward declare a function in the same file as it is defined.
The user needs to write the prototypes, and then magic can scan for the prototypes and generate the stub its self, but they can't currently appear in the same file like in C/C++.
Without both of those things, my new solutions will be worse. More verbose, difficult to read&maintain, slower, and really annoying to debug.
Why are you so against default arguments associating with a declaration? Why is the solution messy?
Default arguments simplify code. If a default is used frequently, it's better to define it in one place, that is easy to change, and appears with the definition. It's self-documenting, and very convenient.