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

Mark Hartoog wrote:
> Obviously I should stop trying to reply to mails while rushing
> to a meeting, since I did not make myself clear at all.
> 
> We have been discussing adding new and thus irregular syntaxes
> to support this case. What I am trying to suggest is why not
> also consider an irregular interpretation of existing syntax.

I fully understand your suggestion.  Let me be very clear
as to why I am opposing it.

> In:
> 
> function C::T C::get();
> 
> We are already interpreting the C::get() to refer to the 
> unspecialized class. Why not also consider the C::T to refer
> to T in the unspecialized class in the case when the function
> and the type both refer to the same class.  

Because that poses some difficulties in other cases.

> This is a rather irregular interpretation. In
> 
> function C::T get();
> 
> the same type refers to the type in the class with default parameters. 


So, given just the prefix:

    function D#(C::T, C::P, E#(C::T), F#(C::P), C::T::T2)

you want to deal with this as a pure lexical stream without
doing anything while parsing the type?

You'll have to in order to do what you suggest since the
next tokens could either be "C::method" in which case all
of the "C" references are to unspecialized names or the
next token could be just "some_name" in which case the
names all refer to types within the default specialization.

That is the kind of nasty case that I am trying to avoid since
I am not sure that this can even be done correctly in all
cases.

This also implies that simple mistakes that could bind
to names in the context of C and also a parameter of C
might be very difficult to discover, particularly if they
denote the same type initially.  This could lead to very
odd errors if one of the types changes much later in
the development cycle.

Finally, in non-trivial cases, this is much more ugly than
the other variants of syntax *in addition* to having the
special semantics for the name binding.

All of this stuff is easy in the simple cases but gets
pretty nasty in the general cases and is made more
complex by the verbosity of the description.  I would
much prefer something like:

    function #(type T, P) D#(T, P, E#(T), F#(P), T::T2)

for the extern case and have a direct match with the
function return type since it is going to be really
nasty for the users (and the implementation) if we
don't.

And, yes, we've seen stuff that resembles this (not
quite this complex, but along this line).  Once you
start composing parameterized class types with
each other (say a bag of pair<boxes of T, list of T>)
you do get very interesting type expressions.  I
don't want this to become a mess either on the
implementation side or on the usability side.


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.