RE: [sv-ec] Issue 62 / Mantis 2606 -- type binding and method prototypes

I think this example should be an error. In the extern prototype 'T' binds to the 'T' outside the class. In the out of block declaration, 'T' binds to the 'T' in the class. The two are not the same, so it should be an error.

I don't think we need additional restrictions to prevent the user from doing this.

-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of Gordon Vreugdenhil
Sent: Friday, April 24, 2009 10:59 AM
To: SV_EC List
Subject: [sv-ec] Issue 62 / Mantis 2606 -- type binding and method prototypes


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.


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