[sv-ec] Mantis 1857 - extern method types for parameterized classes

In the last meeting, I agreed to write an informal proposal for Mantis
item 1857. 

 

To recap, the problem is how should users specify the function return
type in an out-of-body implementation of a method whose return type is a
class parameter. As I mentioned in the meeting, I prefer to address the
issue in a more narrow manner than Gord's last proposal.

 

This proposal is based on the observation that there already exists
syntax that naturally designates a class parameter when used in the
prototype of an out-of-body method implementation (and in particular the
return type). The syntactical construct is:

class_identifier::parameter_identifier

 

At present, the LRM is ambiguous as to the meaning of this syntactical
construct when used to specify the return type of a method
implementation outside the body of the class declaration. In that
context, two possible meanings can be associated with this construct:
(1) the name of the (unspecialized) parameter, or (2) the default
specialization of the parameter. By explicitly defining this syntax to
designate the (unspecialized) parameter when used in the prototype of an
out-of-body method implementation we solve two problems: We resolve the
ambiguity and we provide a natural syntax to specify the class parameter
outside the class declaration. 

 

I believe this interpretation makes sense because in the context of an
out-of-body method implementation, designating the (unspecialized)
parameter rather than the default specialization is more much more
common and useful. For those rare cases in which users wish to designate
the default specialization in the method implementation, they can do so
via the more explicit and unambiguous syntax. Hence, assuming a class C
parameterized by parameter P, this proposal defines the following
interpretations within the prototype of an out of body method:

 

            C::P                  =>  The (unspecialized) parameter P of
class C

            C#()::P              =>  The parameter P of the default
specialization of class C

            C#(T)::P            =>  The parameter P of the
specialization to "T" of class C

 

Note that the last two have the exact same meaning in any other context,
the only distinction is for this context is the first form. Note that
Gord's proposal also provides for a similar irregularity. The benefit of
this proposal is that it is backward compatible.

 

Example:

 

class C#(type T = int);             // class declaration:

   extern function T f(T x);

   extern function T g(bit b);

endclass

 

// Out-of-body implementations:

 

function C::T C::f(T x);

    ...

endfunction

 

function C::T C::f(bit b);

    ...

endfunction

 

Note that under the proposed rules, the following definition would be
equivalent (the proposal is to treat the prototype of a method
implementation differently):

 

function C::T C::f(C::T x);

    ...

endfunction

 

IMHO, the above definition completely addresses the original problem in
an intuitive manner. This can be made clear in the LRM by  adding a
sentence that states: Any reference to the parameterized class name in
any other type context shall denote the default specialization.  



Putting the above interpretation aside, I discovered that there is merit
to Gord's idea of giving users the ability to specify a class scope for
the purpose of out-of-body method implementations. However, using the
extern keyword for that purpose was very controversial, so I came up
with the following alternate syntax:

 

use class class_identifier;

    // method implementations here

endclass

 

For example, using the previous example, we can declare both methods
using the following:

 

use class C;

    function T f(T x);

        ...

    Endfunction

 

    function T g(bit b);

        ...

    endfunction

endclass

 

Note that this syntax des not add any new keywords (the "use" keyword is
part of the configuration syntax). I discussed this with several users
and they found that this syntax fairly intuitive. Therefore, my proposal
is to allow both syntactical forms: the special definition of C::T in
the prototype of an out-of-body method prototype, and the new syntax
that re-uses the "use class" keywords to re-introduce the class scope
for the purposes of implementing the out-of-body methods.

 

            Arturo

 

PS - I will not be able to attend next Monday's meeting.

 


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.