Bug in function parameters type matching

[EntangledQuanta via Digitalmars-d]

A very strange bug.

I had a function like

interface I { foo(string x, anEnum e); }
abstract class A : I { }
class C : A { foo(string x, anEnum e) { } }

I decided I needed to extend foo so I changed it to

interface I { foo(string x, int y, anEnum e); }
abstract class A : I { }
class C : A { foo(string x, int y, anEnum e) { } }

but I forgot to change the only call to foo I had, which was

foo("asdf", anEnum.x);

I ran the code and it all compiled but, of course, was bugged 
because inside foo y was 1, which was the value of anEnum.x.

I thought dmd would through an error since, anEnum is not an int, 
yet it didn't.

Seems like dmd is broke somewhere.


Here is an (non)working example:

enum anEnum { x }
interface I { void foo(string x, int y, anEnum e = anEnum.x); }
abstract class A : I { }
class C : A { void foo(string x, int y, anEnum e = anEnum.x) { } }

void main()
{
   auto i = cast(I)(new C());
   i.foo("asdf", anEnum.x);
}

note that it removing the enum's default value gives the proper 
error. Having the default value shouldn't change anything as far 
as errors are concerned because, unless enum's are implicitly 
castable to int's, which someone once told me that D didn't like 
implicit casts because of issues, it should throw an error about 
type mismatch.

One can even do something like this:

enum anEnum { x }
interface I { void foo(string x, double y, anEnum e); }
abstract class A : I { }
class C : A { void foo(string x, double y, anEnum e) { } }

void main()
{
   auto i = cast(I)(new C());
   i.foo("asdf", anEnum.x, anEnum.x);
}

or even

enum anEnum { x }
interface I { void foo(string x, byte y, anEnum e); }
abstract class A : I { }
class C : A { void foo(string x, byte y, anEnum e) { } }

void main()
{
   auto i = cast(I)(new C());
   i.foo("asdf", anEnum.x, anEnum.x);
}

which is just wrong. I realize enum is a literal BUT there should 
be some type of type checking. The whole point of using an enum 
parameter is to enforce type safety.

Those that justify this case then justify other contradictory 
cases(such as, "Oh, we can't have implicit casting here because 
it will introduce bugs") are just posers.