Mantis 2606 raises a very difficult issue in terms of class type/name resolution. Here is one of the examples: typedef int T; class c; extern function foo(T p); ==> resolves to T outside class? typedef real T; endclass function c::foo (T p); ==> resolves to T inside the class endfunction The key question is whether "T" binds to the outer or inner typedef and what the out of block declaration does. The Mantis suggests that the prototype should be parsed with respect to the type name "T" present in the class. I don't think that is feasible. That solution raises most of the concerns that several of us have raised with respect to parsing arbitrary declarations in the context of names that you do NOT know are types. I consider this example to be a fairly absurd edge case -- there is little in the way of compelling reasons for a user to structure their code in such a manner; they could easily just move the type up in the class and avoid any ambiguity. This could also introduce significant differences between prototype handling and full method handling -- would a non-prototype method follow the same rules? Then lack of knowledge that a name is a type is a serious issue. If not, you now have truly bizarre type binding rules. As a result I am loathe to substantially impact the complexity of the type rules in order to adopt what the Mantis suggests and would oppose that suggestion. I would be fine with a restriction saying that it would be an error if a type name is used in a prototype and that name is subsequently rebound to a new type within the class. That is somewhat similar to how C++ restricts type visibility/redefinition within classes as well but the impact in SV is restricted to just the method prototypes which cause the issues. 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.Received on Fri Apr 24 11:00:50 2009
This archive was generated by hypermail 2.1.8 : Fri Apr 24 2009 - 11:02:29 PDT