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

Of the syntax bases solutions, I definitely prefer the 
'C::function' solution.

Since some people disliked this, I thought we should get all the
possible solutions on the table for people to consider. It is 
either some funny syntax that some people don't like, or it is a
funny interpretation of existing syntax that some people don't like.

Take you pick.

What about the 'C::T::T2' and 'T::T2' in your example below? Is that 
just a typo or is it suppose to be legal?  

> -----Original Message-----
> From: Gordon Vreugdenhil [mailto:gordonv@model.com] 
> 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.