[Issue 4028] delegates with differing default arguments lead to same template instantiation

2011-07-03 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=4028


yebblies  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 CC||yebbl...@gmail.com
 Resolution||DUPLICATE


--- Comment #10 from yebblies  2011-07-03 22:22:51 EST ---
*** This issue has been marked as a duplicate of issue 3646 ***

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 4028] delegates with differing default arguments lead to same template instantiation

2011-06-08 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=4028



--- Comment #9 from yebblies  2011-06-08 07:30:13 PDT ---
*** Issue 4664 has been marked as a duplicate of this issue. ***

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 4028] delegates with differing default arguments lead to same template instantiation

2011-04-06 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=4028


Don  changed:

   What|Removed |Added

 CC||clugd...@yahoo.com.au


--- Comment #8 from Don  2011-04-06 07:10:00 PDT ---
(In reply to comment #7)
> Is it possible/good to encode the simple constant default arguments (ints,
> strings, etc) in the type/signature of the delegate, and refuse the other 
> types
> of default arguments?

What good would adding that corner case be?
I think it's just a bizarre and silly feature. It's a horrendously complicated
and confusing way of doing one special case of currying.
If you really need this ability (which I doubt), you can achieve the same thing
via a struct with two opCall overloads.

Just kill it.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 4028] delegates with differing default arguments lead to same template instantiation

2011-04-06 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=4028


bearophile_h...@eml.cc changed:

   What|Removed |Added

 CC||bearophile_h...@eml.cc


--- Comment #7 from bearophile_h...@eml.cc 2011-04-06 03:11:21 PDT ---
Is it possible/good to encode the simple constant default arguments (ints,
strings, etc) in the type/signature of the delegate, and refuse the other types
of default arguments?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 4028] delegates with differing default arguments lead to same template instantiation

2011-04-05 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=4028


Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com


--- Comment #6 from Walter Bright  2011-04-05 
22:15:35 PDT ---
(In reply to comment #4)
> The two delegates *are* the same type, so they are supposed to lead to the 
> same 
> template instantiation. Introducing a default parameter does not create a new 
> type.
> I'm not sure why function pointers with default parameters are accepted at 
> all. 
> I think it should be an error.

I suspect the only way to deal with this is, as you suggest, disallowing
default arguments for function pointers. I don't know what the downside of that
is, though.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 4028] delegates with differing default arguments lead to same template instantiation

2011-01-07 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=4028


Gide Nwawudu  changed:

   What|Removed |Added

   Keywords|wrong-code  |accepts-invalid
 Status|RESOLVED|REOPENED
 CC||g...@nwawudu.com
 Resolution|WONTFIX |


-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 4028] delegates with differing default arguments lead to same template instantiation

2011-01-06 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=4028


nfx...@gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX


-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 4028] delegates with differing default arguments lead to same template instantiation

2010-08-17 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=4028


Jonathan M Davis  changed:

   What|Removed |Added

 CC||jmdavisp...@gmail.com


--- Comment #5 from Jonathan M Davis  2010-08-17 
19:11:33 PDT ---
Well, either they need to be separate or default parameters for function
pointers, delegates, and lambdas need to become errors. It seems like it might
be nice for them to be able to have default parameters, but the more I think
about it, the weirder it seems. I'm not quite sure why that would be all that
useful. It seems like it's trying to subvert the type of function by currying
it.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 4028] delegates with differing default arguments lead to same template instantiation

2010-04-08 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=4028



--- Comment #4 from Don  2010-04-07 23:56:51 PDT ---
The two delegates *are* the same type, so they are supposed to lead to the same 
template instantiation. Introducing a default parameter does not create a new 
type.
I'm not sure why function pointers with default parameters are accepted at all. 
I think it should be an error.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 4028] delegates with differing default arguments lead to same template instantiation

2010-04-04 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=4028



--- Comment #3 from nfx...@gmail.com 2010-04-04 03:53:30 PDT ---
Before I'm trying to forget this bug while cursing dmd to hell and inventing
awkward, code-inflating work arounds in my code, here's a simpler test case
that demonstrates the bug:

import std.stdio;

alias void delegate(int x = 123) Dg1;
alias void delegate(int x) Dg2;

void main() {
   writefln("%s", Dg1.stringof);
   writefln("%s", Dg2.stringof);
}

Output, expected:
void delegate(int x = 123)
void delegate(int x)

Output, actual with dmd 1.057:
void delegate(int x = 123)
void delegate(int x = 123)

Don't forget that this doesn't really scratch the template instantiation issue;
one could say that there are actually two bugs: 1. accidentally merging the
types Dg1 and Dg2 into one type, and 2. template instantiations with
delegates/functionpointers that have default arguments.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 4028] delegates with differing default arguments lead to same template instantiation

2010-04-04 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=4028



--- Comment #2 from nfx...@gmail.com 2010-04-04 03:48:24 PDT ---
I decided that this bug can't be fixed. Even if you'd try to make it behave
correctly, you would somehow have to include the default arguments expressions
into the name mangling of template instantiations.

What are you going to do, Wallter?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 4028] delegates with differing default arguments lead to same template instantiation

2010-03-29 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=4028



--- Comment #1 from nfx...@gmail.com 2010-03-29 16:16:23 PDT ---
PS: the worst thing about this bug is that the actual delegate type the
template is using is practically chosen randomly. E.g. the program above thinks
moo4 has a default argument. If you switch the order method!(Foo, "moo3") and
method!(Foo, "moo4") are called, moo4 will be handled correctly, but it thinks
moo3 has a required argument.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---