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

Mike Mintz and I exchanged a fair amount of email on the
issue of dealing with return types for extern functions of
parameterized classes.  We agree that, as in C++, one needs
to be able to determine that names in the function return
type can be recognized as such prior to parsing the return type.

We didn't agree on the style that should be used for such declarations.

Here is the original simple example:

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

Here are some alternatives that we discussed for the external definition:
   1)  C::function T get();    // what I originally proposed
   2)  function::C T get();
   3)  function #(type T = int) T C::get();


Some of the points in the discussion:
   a) (3) is essentially what C++ does for template methods;
      the template formals are duplicated and the combination
      of that and the "C::get" gives you what you need.
   b) (1) or (2) are just "short hands" for (3)
   c) (2) could permit a full duplication of the template
      parameters if we wanted:
         function::C#(type T = int) T get();
   d) (1) and (2) would allow but not require the class prefix
      (C::) prior to "get".  (3) requires C::get.
   e) If we adopt some variant of Mantis 696 (parameterized
      tasks and functions) then (3) has a very symmetric
      form with how parameterized functions would look, with
      just the class prefix "C::" to indicate that is the
      definition of an external (this is what C++ has as well).

The symmetry argument is very reasonable but I personally
don't find it completely compelling.  I have a pretty
strong bias against forced redundancies and the required
cut-and-paste of the parameterization provides more
opportunities for error with the symmetry being the only
benefit.

I would be happier with a modified form (that Mike and I
didn't discuss):
    4) function #(type T) T C::get();
since then at least you don't have to repeat defaults.


Any of these solve the fundamental problem.  My preference
is still (1) with (2), (4) and (3) being my choices in
decreasing preference.

We should take this up in committee, but I would like to
see if we can reach consensus on a preferred form via
a straw poll of the group.  If there is a reasonable level
of consensus on one form, I'd be happy to write that up
prior to the next meeting.

Mike, I hope that I conveyed the core of the discussion
in a fair manner.  If I mischaracterized anything, please
jump in.  Thanks for the great discussion; your input
is very valuable.

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.