www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - DMD 0.95: mixin functions are overridden even if they have a different

reply Burton Radons <burton-radons shaw.ca> writes:
This code fails compilation with the errors:

    foo.d(17): function gah (char[]x) does not match argument types (int)
    foo.d(17): cannot implicitly convert int to char[]

This appears to be because the mixin gah is overridden by the struct 
gah.  I imagine this is a bug in the mixin overridding rules, as two 
functions with the same name but a different argument set are not the 
same function.  I'd suggest that a mixin symbol should never be 
overridden unless if the type is the same.  For variables, that would 
mean that if the type is different, it's an error.

    template a ()
    {
       void gah (int x) { }
    }

    struct b
    {
       mixin a;
       void gah (char [] x) { }
    }

    void main ()
    {
       b s;

       s.gah ("foo");
       s.gah (4); // errors occur here
    }
Jul 18 2004
next sibling parent John Reimer <brk_6502 NO_S_PAM.yahoo.com> writes:
On Sun, 18 Jul 2004 09:18:35 -0700, Burton Radons wrote:

 This code fails compilation with the errors:
 
     foo.d(17): function gah (char[]x) does not match argument types (int)
     foo.d(17): cannot implicitly convert int to char[]
 
 This appears to be because the mixin gah is overridden by the struct gah. 
 I imagine this is a bug in the mixin overridding rules, as two functions
 with the same name but a different argument set are not the same function.
  I'd suggest that a mixin symbol should never be overridden unless if the
 type is the same.  For variables, that would mean that if the type is
 different, it's an error.
 
     template a ()
     {
        void gah (int x) { }
     }
     }
     struct b
     {
        mixin a;
        void gah (char [] x) { }
     }
     }
     void main ()
     {
        b s;
 
        s.gah ("foo");
        s.gah (4); // errors occur here
     }
See my submission to this forum "Dangerous Effects of Import with Class Body" for a similar example of the problem but in a different context. Also Ant has posted several bug reports about name resolution problems. I think your problem with mixins is related to these. In the previous circumstances with imports, Walter has basically said that "name lookup is done before overload resolution." It appears that method signatures are NOT taken into account in all these situations. It's quite annoying. That the problem exists now in mixins, just goes to show the extent of the issue.
Jul 18 2004
prev sibling parent "Walter" <newshound digitalmars.com> writes:
"Burton Radons" <burton-radons shaw.ca> wrote in message
news:cde7ta$2eu4$1 digitaldaemon.com...
 This appears to be because the mixin gah is overridden by the struct
 gah.  I imagine this is a bug in the mixin overridding rules, as two
 functions with the same name but a different argument set are not the
 same function.  I'd suggest that a mixin symbol should never be
 overridden unless if the type is the same.  For variables, that would
 mean that if the type is different, it's an error.
This is expected behavior. D follows the simple lookup rule of "look up the name first, *then* do overload resolution". The type signature is not part of the name. Mixins are in their own scope, and doing a mixin is analogous to doing an 'import' as far as symbol lookup goes. You can use an alias to bring mixin names into the current scope.
Jul 30 2004