On Tue, 28 Aug 2012 04:57:53 -0400, Don Clugston <d...@nospam.com> wrote:
On 27/08/12 16:16, Steven Schveighoffer wrote:
On Sun, 26 Aug 2012 18:26:40 -0400, Manu <turkey...@gmail.com> wrote:
I just updated to 2.60 and found errors throughout my code where
function
pointers default args no longer work.
*Every single project* I've written in D, 5 projects, don't work
anymore,
including my projects at work.
OK, I've read all the posts on this, and this is what I think would
solve the problem:
1. default parameters are part of the function pointer type, because a
function pointer has a type.
2. The mangled name of the function that is assigned to that function
pointer does *not* have default parameters mangled in. Only the
function pointer type has them.
3. Since the default parameters are part of the type, but not defined by
the function it points to, you can use interchangeably functions of the
same type which define default parameters or not (or define different
ones). The default parameters follow the function pointer variable.
This sounds like sloppy thinking.
I _think_ what you are saying is that there should be implicit
conversions from one function pointer type, to any other that has the
same basic declaration, but different default arguments.
But then you get problems with IFTI.
void foo( void function(int x), double) {}
void foo( void function(int x), int) {}
void function(int x = 10) bar;
foo(bar, 5); // fails -- ambiguous. Both overloads match with implicit
conversions.
First, I don't see IFTI anywhere in there.
Second, why is this a problem? We already have oddities in terms of how
implicitly converting one argument makes the interpretation of
non-ambiguous arguments ambiguous.
I don't think it's sloppy, my logic is: we can already (I think) do this
in library code, so why is it impossible for the compiler to figure out?
But really, it seems to me that this whole feature is just syntax sugar
for one special case of currying.
Probably. But it is what it is -- a poorly implemented/designed language
feature. In most cases, we don't simply drop them without giving a
replacement. Examples: octal literals, complex numbers, scope classes.
-Steve
