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

Hi Gord and team,

This is a good and fair summary of what we have discussed. At the risk of
being voted off the island, let me add just a bit of color commentary.

>  1)  C::function T get();    // what I originally proposed

I feel that the user is not served well by this form. For one, it is a new
syntax (decorating the task or function reserved word with a scoping
operator), which cannot be used anywhere else in the language. Second, it
only solves the point problem, not the templated functions one.

Also, the get() function must be implied to be in the C scope, by the
decorated task/function lexeme. That's not intuitive.

>   3)  function #(type T = int) T C::get();

On to Gord's objections.

> 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 agree in principal, but this is a special case.
First, a forced cut and paste helps to give the USER a context as well as
the compiler. Remember, coding is more about communication between users
than it is between user and compiler.

Second, the initial declaration of the class and the final definition of the
templated method may be quite far away from one another. This has been
proven out in how people code C++ templates. We tend to have an interface
file and then at the end, include an implementation file. So, the
replication is not necessarily a bad thing with no benefit.

Third, if you want to solve the replication, allow the parameters to be
packaged up to a single name. But that would probably be more than we want
to solve.

>    4) function #(type T) T C::get();


I think this is a great suggestion. There is also precedent (in C++) for not
having to replicate defaults in the implementation of a templated method.

So, I guess my preference order is (4), then (3). I think (2) and (1) are
way to biased to the compiler and do not make sense to a user.

Take Care,
Mike

On 6/20/07, Gordon Vreugdenhil <gordonv@model.com> wrote:
>
> 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.
>
>

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