www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 1006] New: no ambiguity error given if getting function address

reply d-bugmail puremagic.com writes:
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
next sibling parent Kirk McDonald <kirklin.mcdonald gmail.com> writes:
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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1006


wbaxter gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |wbaxter gmail.com





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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1006






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
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1006


smjg iname.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |DUPLICATE







*** This bug has been marked as a duplicate of 52 ***


--
Feb 25 2007