Re: [sv-ec] Mantis 1609: New updates?

Ben,

The basic point is that the interaction of name resolution rules
involving import and inheritance becomes very muddled.

For example,

    class C;
       int x;
    endclass

    package p;
       int x;
    endpackage

    class D extends C;
       import p::*;
       function f();
          return x;   // is this this.x (from C) or p::x
       endfunction
    endclass

    class E extends D;
       function int g();
          return x + super.x;  // what is "x"?  what is "super.x"?
       endfuntion
    endclass

C++, in order to avoid this issue, also disallows using
a namespace in a class scope.  Either outside the class
or in a method there is never confusion between inheritance
and package (namespace) visibility.  Mixing the two is
very confusing in practice and can lead to very subtle issues.

Complicating the issue is the question of whether imported
visibility is inherited.  If not, then the meaning of "x"
in a class E derived from D reverts back to the inherited
member, not the package element.  That sounds pretty scary
(no override of "x" but the meaning changes).  If one would
say that the package visibility is inherited then how
is it inherited?  Is an overriding declaration now an
error (as it would be in D following function f)?  Does
that mean that an import is a way of saying that an identifier
can no longer be overridden?  What about interactions with
virtual functions?  Pure virtual functions?

There are many awkward questions here.

If a vendor allows this right now, it may be an oversight
or may not have intended consequences in the areas that
I have raised.

If it is intentional, the vendor should step up and offer
a sensible set of rules if they don't want it disallowed.
No one has done so yet.  The feedback from both Synopsys
reps so far has been that the current LRM text overlooked this
case and that such imports should be disallowed.  Cadence
didn't object to this view in SV-BC; I don't know if that
will change in SV-EC.

In terms of the status, I had filed this as an SV-BC
item (due to the imports) but BC felt that EC should
address the issue.  So it is in the hands of EC.  Due to
the face-to-face and on-going discussions regarding other
areas, I don't know where this will fall in the agenda.
If you consider this to be pressing, you could ask Mehdi
to elevate this in the agenda.  At this point, given that
I haven't heard anything negative from any of the vendors,
I am expecting this to be approved when it does come up.


In terms of overall language interpretation and compliance
issues, yes, we are all aware of many issues in that
space.  There are numerous ambiguities and issues that
are (slowly) being resolved.  I am working with a sub-group
of SV-BC to work through name resolution issues; interpretation
differences in that area tend to cause compatibility issues but
there are many interactions that have not been carefully
defined so progress is slow.  When there is disagreement,
progress tends to stop until issues are resolved.  Only
once point issues are resolved can a comprehensive write-up
really have much of a chance; you can go back in SV-BC/EC
archives to see a writeup that I did quite a while ago
describing a basic framework.

And that is all just on name resolution....

My hope is that vendors are being aggressive about complying with
approved Mantis items since that will aid in reaching consensus and
common interpretations more quickly.  Past experience however
suggests that not everyone follows that philosophy.  If you
are aware of vendors that don't comply with the restrictions
proposed in Mantis 1609, it might be worthwhile to ask them how they
intend to respond to it.  If there is disagreement, the community
is far better off if the disagreement is raised early.

Gord.


vhdlcohen@aol.com wrote:

>  
> Mantis 1609 states
> Quote:
> It shall be illegal to have an import statement directly within a class 
> scope.
> 
> 
> 1, What is the status of this mantis? Still under discussion? 
> 2. If the import is outside the class and at root, then the only need 
> for the import would be for synthesis of RTL since the import of a 
> package would be seen by the RTL anyway from root.
> 3. Currently not all vendors have abided by current P1800 that allows 
> the import within a class.
> What about backward compatibility since current P1800 LRM allows import 
> within a class? Users will need to make the necessary changes.
> 3. As of today there are several differences in tool support and 
> understanding (or interpretation) of the LRM. Code that compiles and 
> runs on one tool would most likely not execute on another tool, 
> particularly when the advanced feature of the language are used. This 
> import issue is only one of them.
>  
[...]
-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com