SystemVerilog - virtual class implementing interface - compilation error when interface functions not at least redeclared in virtual class - why?

In this code:

package P;
interface class A;
    pure virtual function a ();
endclass
virtual class B implements A;
    //pure virtual function a (); // why is this needed?
endclass
endpackage
module tb();
initial begin
end
endmodule

I get errors regarding function a() not being implemented in class B. Is that an LRM requirement? And if so, why? I would think that as soon a class is virtual (and not able to be instantiated), it wouldn’t require me to implement or redeclare interface class functions.

Thanks,
Noah

In reply to nachumk:

That error is not correct. Please report this to your tool vendor.

The LRM says in two places that

A virtual class shall define or inherit a pure virtual method prototype or virtual method
implementation for each pure virtual method prototype in each implemented interface class.

and

Because virtual classes are abstract, they are not required to fully define the methods
from their implemented classes

When inheriting a pure virtual method prototype, there is no need to re-declare it in the subclass.

Thank you Dave! That’s super helpful.

In reply to dave_59:

Hi Dave,

Cadence got back to me and it seems like the error is correct. According to the LRM in 8.26.7:

It shall be illegal to use an interface class to partially define a virtual class without fulfilling the interface class prototype requirements. In other words, when an interface class is implemented by a virtual class, the virtual class must do one of the following for each interface class method prototype:
— Provide a method implementation
— Re-declare the method prototype with the pure qualifier

Any reason the LRM mandates this?

In reply to nachumk:

Thanks for pursuing this. I think sections 8.26 and 8.26.7 can interpreted as conflicting rules. 2 of 4 tools on EDAPlayground have come to different conclusions. I will have to take this to the SystemVerilog IEEE committee for clarification.

I think these rules come directly from Java interfaces to make a more formal commitment to eventually implementing the method.

In reply to dave_59:

Thanks again Dave,
Noah