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
   }

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.

"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.