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

Hi Gord, Mark, and the team,

I am getting confused as to what the proposals are. Gord, can I trouble you
to summarize the proposals, going as complex as templated external member
functions ? I'd also love to see the instantiating and calling syntax.  I
may have missed it, but did we consider the derivation from a templated base
class?

I realize this is a lot to ask, but maybe the latest two or three
proposals?

Take care,
Mike

On 6/21/07, Gordon Vreugdenhil <gordonv@model.com> wrote:
>
>
>
> Mark Hartoog wrote:
> > Comments inline below.
> >
> >> -----Original Message-----
> >> From: Gordon Vreugdenhil [mailto:gordonv@model.com]
> >>
> >> 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.
> >
> > Well, I don't find this that nasty to parse. It seem straight forward
> > to me. You interrept the 'C::' prefixes depending on what follows.
> >
> > Why is that so hard?
>
>
> Well, perhaps you understand all the interactions better
> than I.  I am not convinced that all possible type/value
> combinations parse in an unambiguous manner without knowing
> what set of names are types as opposed to values, but I haven't
> come up with a definite example of where they are not.
>
> Given that there would have been ample chance for the closest
> corresponding language (C++) to do what you are suggesting
> and they have not suggests that there may be complexities
> lurking that we haven't run into yet.  My conservative
> approach to design leads me to an approach that most closely
> follows something which has had a much more substantial
> investment in terms of vendor experience and thorough
> user community stressing.
>
> I guess we'll just have to disagree on this.  I don't have
> a compelling and provably ambiguous case so we're down
> to primarily non-technical considerations.
>
>
>
>
> >> 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.
> >
> > I do not like this particular version at all. That looks like a
> > parameterized
> > function, which it is not at all. It is a highly misleading declaration.
> > There is absolutely no reason to repeast the parameter declarations.
>
>
> Well, Jonathan and I both prefer the "C::function" form...
>
> It was feedback from the user community that led to the
> form I used above.  Both Neil and Mike (in the user community)
> have expressed a definite preference for that form.  Perhaps
> they would prefer the form that you are suggesting -- if so,
> I'd definitely want to hear that feedback.
>
>
> In a vote, I would vote against your approach.  Apparently
> you are pretty opposed to the other alternatives that have
> been suggested.  That leaves us in a bit of a tough place;
> I don't really want to treat this as a "count the votes"
> issue.  I think this is a pretty important issue on which to
> reach consensus -- there are definite implications for future
> work and impact on what can be expressed right now.  Vendors
> clearly will need to do something something in this space
> and, based on the discussions here, I suspect that there
> may be divergence in what vendors choose to do if there is
> no direction in the LRM.  That is certainly not a good end
> result for the user community.
>
>
> Anyone else want to proffer an opinion to sway either one of
> us?  User input would be particularly useful here.
>
>
> 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.