digitalmars.D.bugs - [Issue 1006] New: no ambiguity error given if getting function address
- d-bugmail puremagic.com (24/24) Feb 24 2007 http://d.puremagic.com/issues/show_bug.cgi?id=1006
- Kirk McDonald (9/37) Feb 24 2007 This should not be made an error without adding a mechanism to get all
- d-bugmail puremagic.com (30/30) Feb 24 2007 http://d.puremagic.com/issues/show_bug.cgi?id=1006
- d-bugmail puremagic.com (6/6) Feb 24 2007 http://d.puremagic.com/issues/show_bug.cgi?id=1006
- d-bugmail puremagic.com (9/9) Feb 25 2007 http://d.puremagic.com/issues/show_bug.cgi?id=1006
http://d.puremagic.com/issues/show_bug.cgi?id=1006 Summary: no ambiguity error given if getting function address Product: D Version: 1.007 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: bugzilla digitalmars.com ReportedBy: benoit tionex.de this compiles without error. class C { void fnc(){ } void fnc( int a ){ } static this(){ void* ptr = & fnc; //(1) } } I think (1) should be rejected, because of ambiguity. --
Feb 24 2007
d-bugmail puremagic.com wrote:http://d.puremagic.com/issues/show_bug.cgi?id=1006 Summary: no ambiguity error given if getting function address Product: D Version: 1.007 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: bugzilla digitalmars.com ReportedBy: benoit tionex.de this compiles without error. class C { void fnc(){ } void fnc( int a ){ } static this(){ void* ptr = & fnc; //(1) } } I think (1) should be rejected, because of ambiguity.This should not be made an error without adding a mechanism to get all of the overloads of a function, for example: C.fnc.tupleof => Tuple!(void function(), void function(int)) -- Kirk McDonald http://kirkmcdonald.blogspot.com Pyd: Connecting D and Python http://pyd.dsource.org
Feb 24 2007
http://d.puremagic.com/issues/show_bug.cgi?id=1006 wbaxter gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |wbaxter gmail.com ------- Comment #2 from wbaxter gmail.com 2007-02-24 15:31 ------- It's also very common to use overloads for properties. void prop(int p) { return mProp=p; } int prop() { return mProp; } This is a problem for callback/sigslot mechanisms that very often want to call property-like functions. caller ~= (int x){ obj.prop=x; } vs caller ~= &obj.prop; The former introduces an extra layer of indirection, is slightly wordy, and is potentially problematic if 'obj' happens to go out of scope. The latter is currently ambiguous. Apparently a cast can be used currently: caller ~= cast(void function(int))&obj.prop; but it is just too ugly. And it's also semantically incorrect and unsafe. I'm not casting I'm trying to disambiguate. And it's unsafe because the cast will succeed even if obj.prop is a float* or anything else. This is apparently an old proposal (according to Chris N-S) to disambiguate without requiring a cast: caller ~= &obj.prop(int); That would be great if that could be done without making the grammar ambiguous. For generic programming purposes, this should also work: alias Tuple!(int) ArgTup; caller ~= &obj.prop(ArgTup); --
Feb 24 2007
http://d.puremagic.com/issues/show_bug.cgi?id=1006 ------- Comment #3 from wbaxter gmail.com 2007-02-24 15:34 ------- I should add that the problem I spoke of exists only when 'caller.opCatAssign' is a template that accepts multiple function/delegate signatures. If its opCatAssign takes a particular signature then there's no problem. --
Feb 24 2007
http://d.puremagic.com/issues/show_bug.cgi?id=1006 smjg iname.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE ------- Comment #4 from smjg iname.com 2007-02-25 10:32 ------- *** This bug has been marked as a duplicate of 52 *** --
Feb 25 2007