Hi Gord, Yes, that change helps. Attached is a marked up version that has some other changes that I think improves the text. Stu told us yesterday that the word must has been deprecated by the IEEE, so we should make at least that set of changes. I forgot to add in the change that you are showing below. It should also be added. After thinking over this some more, I am in agreement with what you are showing in the proposal. The typedef example is very useful, since it will catch some people by surprise. Neil Gordon Vreugdenhil wrote On 11/16/07 03:55 PM,: > Neil, it is only in the context of a "::" prefix that you don't > get the default specialization. > > So given my class C: > > C some_obj = new; > struct { C field; } s; > C some_arr[$]; > > some_module #(C) m(); > > are all fine and "C" means "the default specialization" in those > contexts. This preserves compatibility with the existing > LRM provisions and implementations. > > I should probably make sure that no one tries to apply the quoted > sentence out of context by saying: > > When referencing a default specialization as the prefix to the > class resolution operator, the explicit default specialization > form of "#()" must be used. > > Does that help? > > Gord. > > > > Neil Korpusik wrote: > >>Hi Gord, >> >>I am having trouble understanding one aspect of your example (the use of the >>typedef). In the new proposed text there is the following statement. >> >> References to the default specialized type must use the explicit >> specialization form "#( )" with no actuals. >> >>But then in the example you are using a typedef which does not use "#()". >>The comment says that the typedef defines T to be the default >>specialization. I am having a problem seeing how this is so. >> >> Example: >> class C #(int p = 1); >> static task t; >> int p; >> int x = C::p; // C::p disambiguates p >> // C::p is not p in the default specialization >> endtask >> endclass >> >> int x = C::p; // illegal >> int y = C#()::p; // legal; refers to parameter p in default >> // specialization of C >> typedef C T; >>--> int z = T::p; // legal; the typedef defines T to be the default >> // specialization so T::p refers to the p in the >> // default specialization >> >>Neil >> >> >> >>Gordon Vreugdenhil wrote On 11/16/07 02:14 PM,: >> >>>I've uploaded a proposal for Mantis 1857 that I believe captures >>>the agreed upon behaviors from the last name resolution meeting. >>>Please review asap and let me know if there are any substantive >>>problems. >>> >>>Gord. >> > -- --------------------------------------------------------------------- Neil Korpusik Tel: 408-276-6385 Frontend Technologies (FTAP) Fax: 408-276-5092 Sun Microsystems email: neil.korpusik@sun.com --------------------------------------------------------------------- -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Section 8.22
Change
class_identifier :: { class_identifier
:: } identifier
The left
operand of the scope resolution operator :: shall be a class
name, package name (see 25.2), covergroup type name, coverpoint name or cross name
(see 18.5, 18.6).
TO:
class_identifier :: { class_identifier :: } class_type :: { class_type :: }
identifier
The left operand of the
scope resolution operator :: shall be a class type
name, package name (see 25.2), covergroup type name, coverpoint name or cross name
(see 18.5, 18.6).
Add at the end of existing 8.22 text:
The class
resolution operator has special rules when used with a prefix that is
the name
of a parameterized class; see 8.24.1 for details.
Section 8.23
CHANGE:
Out-of-block declarations must be declared in the same scope as the class declaration.
TO:
Out-of-block
declarations must be declared in the same scope as the class
declaration.
An out-of-block
declaration must
shall
be declared in the same scope as the class declaration and shall follow the class declaration. It shall be an error if more than one
out-of-block declaration is provided for a particular extern method.
The class
resolution operator is required in some situations in order to name the
return
type of a method with an out-of-block declaration. The
return type of an
out-of-block declarations
is encountered declaration
shall be specified prior to the out-of-block indication for the
method. When the return type of the
out-of-block
declaration is defined in
within
the class, the scope resolution operator must
shall
be used
to indicate the correct return type.
Example:
class C;
typedef int T;
extern function T f();
endclass
typedef real T;
function
C::T C::f();
return 1;
endfunction
Add at the end of existing 8.24 text:
8.24.1
Class
resolution
operator for parameterized classes
Use of the
class resolution operator with a prefix that is the unadorned
name of a parameterized
class (see 8.24) shall be restricted to use within the scope of the
named
parameterized class and within
its out-of-block declarations (see 8.23). In
such cases, the unadorned
name of the parameterized class does not denote the default
specialization but is used to unambiguously name
refer
to members of the parameterized
class. References to the default
specialized type must
shall
use the explicit specialization form “#( )” with no actuals.
Example:
class C #(int
p = 1);
static task t;
int p;
int
x = C::p;
//
C::p disambiguates p
//
C::p is not p in the default specialization
endtask
endclass
int x =
C::p;
// illegal; C::
not allowed in this scope
int y =
C#()::p;
//
legal; refers to parameter p in the default specialization of C
typedef C T;
int z =
T::p;
// legal; the typedef
defines T to be the default
//
specialization so T::p refers to the p in
the
//
default specialization
In the
context of a parameterized class method out-of-block declaration, use
of the class
scope resolution operator shall be a reference to the name as though it
was
made inside the parameterized class; no specialization is implied.
Example:
class C #(int
p = 1, type T = int);
extern static function
T f();
endclass
function C::T
C::f();
return
p + C::p;
endfunction
initial
$display(“%0d
%0d”,
C#()::f(),C#(5)::f()); //
output is “2
10”
This archive was generated by hypermail 2.1.8 : Fri Nov 16 2007 - 21:26:31 PST