Re: [sv-ec] Follow-up from last call -- legality of virtual/pure virtual overrides

Neil,

My (academic) argument for why one could omit "virtual" on
"d" is that the method in "d" isn't actually pure if you assume
that the implementation can be inherited.

Personally, I'm fine with your (assumed) rules. Briefly,
it boils down to the following clarification:
        It is not legal to define a pure virtual prototype for
        an inherited method unless the inherited method
        is itself pure virtual.

A related clarification might be:
        It is not legal to declare a pure virtual prototype for a
        method in the same class in which the method is
        defined.

Given the above, "d" is clearly illegal since the method
definition from "c" can't be inherited. That means that
there is no possible rationale for claiming that "f" is
implemented in "d" and there is then no need to
explicit say that the *syntax* "pure virtual"
requires the class to be virtual -- that is not needed
since the syntax and semantics would be aligned.

So, I'd prefer to go with the above clarification(s) and would
be willing to open a Mantis with a proposal on that if
there are no objections.

Btw, you might recall that the origination of the entire issue
was related to using "inheritance" to describe the
relationship between an interface class method and the
implementing class -- the above clarification would make
it quite important to correct that wording.

Gord.

On 6/24/2011 3:55 PM, Neil Korpusik wrote:
> It is my understanding that pure virtual methods are only allowed within
> an abstract base class. That would make class d in your example illegal.
> function f in class d can't be declared pure.
>
> If we change the example to be the following, I would still say it is
> illegal. In this version, abstract base class d is changing function f
> from
> a virtual to a pure virtual function. Since the definition of pure
> virtual
> is that there is no implementation, I don't see how this could be legal.
> It would be very confusing to say that the new definition of f in d
> overrides what is in c to now not have an implementation.
>
> module top;
> virtual class c;
> virtual function void f(int a); endfunction
> endclass
> virtual class d extends c;
> pure virtual function void f(int a);
> endclass
> endmodule
>
>
>
> Neil
>
>
>
> On 06/24/11 09:10, Gordon Vreugdenhil wrote:
>> This is just to follow-up the questions that I raised in the last EC
>> call.
>>
>> Is the following legal:
>>
>> module top;
>> virtual class c;
>> virtual function void f(int a); endfunction
>> endclass
>> class d extends c;
>> pure virtual function void f(int a);
>> endclass
>> endmodule
>>
>> There are a couple of questions about the legality:
>> 1) can "c" provide an implementation for a later
>> "pure virtual" prototype?
>> 2) if (1) is permitted, can "d" be non-virtual?
>> 3) if (1) is not permitted, can the "f" in some
>> further extension of "d" call "super.f"?
>>
>> If the "f" in "d" is supposed to "hide" the virtual
>> definition in "c" (which I find very troublesome),
>> is the prototype permitted to change? i.e. can you
>> then have:
>> pure virtual function void f(reg a);
>> as the prototype in "d" -- "hiding" generally means
>> the incompatibility is Ok.
>>
>> None of these situations are clearly addressed by
>> the current rules and definitely impact how we talk
>> about various interface class / class interactions.
>>
>> Gord.
>>
>

-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.