[sv-bc] Issues regarding default specialization of class

From: Alok Kumar Sinha <aksinha_at_.....>
Date: Wed Apr 29 2009 - 03:49:15 PDT
Hi,

I have two issues regarding default specialization of class:

1) According to LRM P1800-2009-draft7a, section 8.24.1,

"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."

Now for the 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

So, for the return type of function 'f',  any specialization is not 
required as the function is itself a method of that class
and is only declared outside.

But one of the standard simulaters which supports this type of semantic 
check, is failing on the csae and is expecting
a specialization for return type too.
Am I missing something or is it a simulater bug.

Here I also want to raise an implementation issue.

If the function is defined as :
function C::T f();
    return p + C::p;
endfunction

It is definitely an error as this function is not the method of the 
class C.
But it is difficult to detect the error, because it is clear that any 
error for C::T can only be detected
after function name is found during parsing. Is it the real intention of 
the LRM?

2.  How can we decide for any specialization if any class is forwardly 
declared.
For e.g. ,
module top;
    typedef     C;
    initial
        begin
            C:: x = 1;     // Is the specialization is required or it is 
an error ?
        end
    class C #(parameter int p = 1, parameter type T = int );
        static T x;
    endclass
endmodule

When C::x is declared we do not know whether C will a parameterized 
class or not.

The Mantis 1857 due to which the text added in the LRM is silent on that.

Please anyone give suggestion regarding this.

Thanks and Regards
Alok






-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Wed Apr 29 03:52:08 2009

This archive was generated by hypermail 2.1.8 : Wed Apr 29 2009 - 03:53:01 PDT