[sv-ec] extern methods of parameterized classes - new proposal framework

Based on today's SV-EC meeting, the following is
a preliminary description of some rules that seemed
to have fairly broad agreement.  If there is any
substantive disagreement to this direction, please
let me know by noon Pacific time on Thurs, 6/28
so that I don't waste time formalizing this as a proposal.
Fine tuning feedback is welcome at any point.


Back to the original example:

    class C #(type T = int);
       extern function T get();
    endclass


The suggestion is that we use the following form for
the extern body definition:

    extern class C #(type T = int);
       function T get();
         ...
       endfunction
    endclass


This has a minor impact on the BNF:

    class_declaration ::= // from A.1.2
         [ extern ] [ virtual ] class [ lifetime ]  ......


In terms of semantics, here is what I would require:
    1) an "extern" class shall occur only in the scope in which
       a corresponding class declaration occurs or, in the
       case of a nested class, in the context of an "extern"
       class definition for its parent class.

    2) an "extern" class may only be defined after the class declaration
       has been defined.  It is illegal to have an "extern" class
       declaration for a forward typedef whose declaration has not
       yet been seen in the scope.

    3) an "extern" class shall only contain method definitions or
       nested "extern" class declarations.  Any
       method definition in the "extern" class must be declared
       as an "extern" method in the corresponding class declaration.

    4) If "virtual" or a lifetime is specified in the "extern"
       class, the specification shall match the class declaration.
       If "virtual" or a lifetime is not specified, the
       specification shall apply from the class declaration.

    5) if a parameter_port_list is specified by the extern class it
       shall be identical to the parameter_port_list specified in
       the class declaration.

    6) that each method within the body of the extern shall be treated
       as an out-of-block method definition.


I have phrased 1-5 in a fairly permissive manner which would permit:

    extern class C;
       function T get();
         ...
       endfunction
    endclass

I don't mind adopting a stronger set of rules with respect
to (4) and (5), namely that the form shall match exactly
rather than saying "match if present".  The stronger from
would allow for relaxation along any front in the future.


I think that (6) is a pretty general statement that covers a bunch of
possible illegal forms.  If anything isn't covered, I would consider
that to be a separate issue.  For example, since duplicate
out-of-block declarations of a method are (should be?) illegal,
duplicates defined by "extern class" declarations would also be
illegal.  Duplicates via a "mix-and-match" of forms would also be
illegal.  It would be legal to have multiple "extern class" blocks
with some of the methods in each block as long as no duplicates were
defined.


As a side note -- I don't see any text in the LRM that restricts
duplicate out-of-block declarations.  I'd prefer to deal with
that issue and any other issues with respect to the current form
of out-of-block declarations separately so that we can essentially
just treat the "extern class" form as a collection of out-of-block
declarations in terms of the rules.  The only interesting case that
we likely should spell out is that when definiing an extern function
whose type is defined by a parameterized class, one must use the
"extern class" form to correctly refer to the type.

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.