Re: [sv-ec] Scope resolution operator (::) to access class parameter assignments

Brad Pierce wrote:

> Is it legal to access a parameter of a class specialization using the 
> scope resolution operator (::)?
> 
> For example, near the end of 7.23, would it be legal to refer to the 
> following?
> 
>                          Stack4::T::size
> 
> I would’ve assumed ‘yes’, but this is not explicitly mentioned in 7.21 
> and there are no examples of such usage in 7.23.

I agree that it is isn't explicitly mentioned, but I consider
"Stack4" to be a class identifier in the same way that I would
consider C_2 to be a class identifier in:
    class C;
    endclass
    typedef C C_2;
Since a typedef of a specialization is just a name for the
(specialized) class type, I think the "class identifier"
part of the scope resolution rules apply to it.
I consider the same to hold if a type parameter resolves to
a class (which is implicit in your use of "T::size").

I don't know if this needs a minor clarification; unless
one wants to argue that C_2 in my example would be illegal
as a "class identifier", I think that this falls out of the
existing text.

Note that this does mean that in such cases "::" can't be
resolved until elaboration time; I haven't come up with
anything that causes problems with that.

I haven't really decided on whether stack#(Vfour)::T::size is
useful enought to try to add to the LRM; at this point I consider
that to be illegal on the narrow grounds that "stack#(Vfour)" is not
a simple type identifier.  There is nothing conceptually wrong with
it, but I think that realistically one will have a named
specialization anytime that one wants to do this.

I'm not sure whether it should ever be valid to use "::" with a
parameterized class name. Using the "stack" example from 7.23, if
you have:
     stack foo;
then foo is a class object whose type is an implicit specialization
of "stack" with the default parameters.  This already confuses
people into thinking that "stack" is a type.  If you also
allow:
     stack::T some_local;
things would get pretty confusing -- "stack" here is not the
parameterized class, it is an implicit specialization with the
default parameters and "T" is thus the default type for T,
ie. "int".   Since "stack" is an identifier, one could make
the case that this should be permitted.  Although this is
defensible, I think that it might add to some of the  current
confusion that already exists in terms of the difference
between a parameterized class and a type.

If it weren't for the special magic default type for mailbox,
I'd seriously suggest eliminating such implicit specializations
and always requiring at least "stack #()" so that users know
that a specialization is there.

Gord.
-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com