class A : B
{
  override Void doSth(Bool checked)
  {
    echo("A $checked")
  }
  Void main()
  {
    (this as B).doSth
  }
}

mixin B
{
  virtual Void doSth(Bool checked := false)
  {
    echo("B $checked")
  }
}

That gives

sys::Err: java.lang.AbstractMethodError: fan.test_0.A.doSth()V
  test_0::A.main (/C:/temp/test.fan:9)
  java.lang.reflect.Method.invoke (Unknown)
  fan.sys.Method.invoke (Method.java:552)
  fan.sys.Method$MethodFunc.callOn (Method.java:230)
  fan.sys.Method.callOn (Method.java:139)
  fanx.tools.Fan.callMain (Fan.java:137)
  fanx.tools.Fan.executeFile (Fan.java:88)
  fanx.tools.Fan.execute (Fan.java:34)
  fanx.tools.Fan.run (Fan.java:250)
  fanx.tools.Fan.main (Fan.java:288)

on attempt to run.

Also this.doSth refused to compile with

C:\temp\test.fan(9,10): Invalid args doSth(sys::Bool), not ()
ERROR: cannot compile script

for B declared as either mixin or class

Promoted to ticket #1501 and assigned to brian

I will have to consider what to do there. I've debated whether subclasses should be forced at compile time to maintain the same defaults as the overridden method.

Renamed from overriding mixin method does not inherit default to ensure override has matching param default state

Ticket resolved in 1.0.59

For now, I changed the compiler to do more stringent checking on overrides. The parameters of an override method must have or must not have a default based on the base class/mixin's method. If your override adds/removes default parameters then you will now get a compiler error.

We actually had a couple cases where I did this in our SkyFoundry code base. But it was more sloppy programming than any real need. So we'll start off strict and can always decide to relax restrictions in the future.