[sv-ec] "::" is ambiguous in parameterized classes

From: Gordon Vreugdenhil <gordonv_at_.....>
Date: Thu Oct 04 2007 - 08:34:38 PDT
This issue came up at the last EC meeting.

Consider the following:
    class C #(type T = int);
       class B #(type T = C::T);
           C::T x;
       endclass
    endclass

The "::" here has two interpretations -- class scope resolution
and resolution into a *type*.  In this situation there is a
difference since the name "C" is overloaded to mean both
the name of the class and the name of the default specialization.

I think that the user intent here is that "C::T" should
mean "T" in the enclosing scope and NOT "T within the default
specialization of C".  If the latter interpretation is chosen,
then there is no way at all to refer to the unspecialized "T"
from C from within the nested class.  If the scope resolution
interpretation is intended, one can refer to the default
specialization as "C#()::T".  This is particularly important
for the default in "B" -- it seems clear to me that the expected
intent would be "I want B to default to the type used to
specialize C".

Putting this along side my comments in
     http://www.eda-stds.org/sv-ec/hm/4647.html
I think there is now a compelling argument to clarify the
LRM by stating something like the following:
     When used with a parameterized class prefix, the "::" resolution
     operator shall only be legal within the parameterized class named
     in the prefix or an out-of-block method declaration of that
     parameterized class.  With a parameterized class prefix, the "::"
     resolution operator shall only disambiguate names, it shall not
     refer to the default specialization of the class.

I will add the example above when I write up a proposal for this.

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 Thu Oct 4 08:34:56 2007

This archive was generated by hypermail 2.1.8 : Thu Oct 04 2007 - 08:35:37 PDT