On 8/26/2012 5:06 PM, Manu wrote:
To be fair, it's not a very lively discussion. Spans 1 day, and only 3 people
comment :)
If you want a lively discussion, start one up about what to name a keyword :-)
Is that really an exhaustive set of options? It seems the other possibility
(including the default arg in the equivalence test) wasn't really considered.
The part that I don't understand is how the situation manifests in the first
place:
auto foo = (int a = 1) { return a;};
auto bar = (int a) { return a;};
writeln(foo()); // writes '1'
writeln(bar()); // writes '1' also!
These are 2 distinct assignments. I would expect foo and bar /would/ each take a
type that is technically equivalent, but foo's type would have the bonus default
arg in its type record, just as a function pointer that were declared
explicitly.
That's the way it used to work. The problem is, what are those types? Are they
the same types or not? You're saying sometimes they are the same type, sometimes
they are not. It's a mess.
At what point does the compiler become confused? They never interact... The
expected behaviour seems obvious to me, foo and bar should effectively be:
int function(int a = 1) foo = ..;
int function(int a) bar = ...;
It seems obvious only in the trivial case. What if you passed foo to a function?
Now what type is it? What is the mangling for the type?
I presume if I typed that code, there would be no problem?
The discussion is obviously regarding implementation details...?
No.
The trouble for function pointers, is that any default args would need to be
part of the type, not the declaration.
I thought they were part of the type already? I would have thought that's where
they should be. Why is their new home more 'proper'?
Because are the types the same or not?
I know it broke code (for many others, too), and I'm very sorry about that,
but I don't see another way out.
It's a rather major breakage. I've seen you reject far more important changes
solely on the grounds that they are a breaking change before...
Unfortunately, it was already broken, as the bug report showed. It's a matter of
where the crack shows up.
(Many uses of default arguments can be replaced with overloaded functions.)
Can you suggest how? I can't think of a feasible approach.
I'd have to see what you were trying to do.
You can't overload function pointers (multiple instances of variables with the
same name). And by definition of a function /pointer/, I don't own the target
function to overload it.
I can't reasonably produce static wrappers either, unless the wrapper receives
the function pointer I intend to call as an arg, which is super nasty.
I can probably address the global/static ones via wrappers, but I don't love
redundant function calls, it reduces debug build performance (see: all my rants
about __forceinline), but that would only address the problem in a few
situations.
This also undoes all that good work recently with the parameter list traits >_<
As I see it, calling a function is possibly the single most important thing a
programming language does. Flexibility in this regard is valuable. Default args
in function pointers was a HUGE selling point of D to me, I've made extremely
liberal use of this feature to great benefit throughout all my projects.
But perhaps most importantly, this change has a huge impact on my code at
work... I don't really want to imagine telling my boss that I need to rewrite
the engine bindings and integration code. I'll look like the biggest dick this
side of the Baltic :/
If you can show me a generic example of what you are trying to do, perhaps we
can suggest a reasonable alternative.
