Ambiguous call to overloaded method problem

HI
In the latest stable release, the .NET compiler reports problems with an ambiguous call to a method. The previous releases worked fine with this code. Here is a test case for .net console app :

namespace ConsoleApplication8;
interface
type
  TLayer = class
  end ;
  TLayerClass = class of TLayer;

  Program = class
  public
    class method Main(args: array of String): Int32;
  end;

  TMyLayer = class( TLayer )
  end ;

TReg = class
  class method Register ;
end;

  method RegisterLayer( const _lc : TLayerClass ) ; overload ;
  method RegisterLayer( const _lc : &Type ) ; overload ;

implementation

  class method Program.Main(args: array of String): Int32;
  begin
    RegisterLayer( TLayer ) ;
    RegisterLayer( typeOf(TLayer) ) ;
    TReg.Register;
  end;

  class method TReg.Register;
  begin
    RegisterLayer(  TMyLayer ) ;
  end;

  method RegisterLayer( const _lc : TLayerClass ) ;
  begin
    //
  end;

  method RegisterLayer( const _lc : &Type ) ;
  begin
    //
  end;
end.

Here I get E: Ambiguous call to overloaded method "RegisterLayer". The problem seems to be declarations "class of TLayer" combined with &Type overload. New build either treats these declarations as the same types or the method call fails to recognize a proper option.
How the class of type is generated now?
Is this a bug or a permanent change in the compiler? The Java seems to be affected too.

I suspect these changes :

  • 84835: Oxygene: add implicit cast operator to MetaClasses, to cast to Type
  • 84830: Oxygene: allow passing/assigning direct type references to Type

Yep.

I’f afraid that its going to remain “as designed”, as these now are ambiguous.

What’s the real use case you’re trying to solve here (assuming the provided test case is contrived just too show the issue)? Do you really need overloads that take both a class ref and a system type, and if so, could you work around by giving the methods unique names?

In this situation (cast to Type), I only need a class ref type and can remove overloads. Thanks for your clarification.

1 Like

That said, I’ll discuss with the team if we can actually make the work. even though class of and type are now implicitly castable, one or the other method shoudkl still be the better (no-cast) fit.

@ck, what do you think?

Thanks, logged as bugs://84929

bugs://84929 got closed with status fixed.

1 Like