RE: [sv-bc] Query related with the visibility of enum member.

Greg,

I don't see the need for anonymous types in SV. Is there one? More generally, we seem to spend an inordinate amount of time on anonymous generate blocks, anonymous sequential blocks containing declarations, anonymous types. Is there any advantage to these besides not needing to invent a name?

Under the assumption that, because of "legacy", we couldn't simply forbid anonymous types, even if they were worthless, I'm with you until the concluding paragraph

>I think saying int a = mystruct :: NO; would be the right way to access this label.
>I also think an enum type name should function as a scope for accessing its labels.

Other than convenience, why wouldn't it be one or the other of these, not both?

-- Brad

From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Greg Jaxon
Sent: Friday, May 14, 2010 10:11 AM
To: Rich, Dave
Cc: Dhiraj Kumar Prasad; sv-bc@server.eda.org; Surya Pratik Saha
Subject: Re: [sv-bc] Query related with the visibility of enum member.

What Dave says is true, but it does not address why systems have diverged.
This enum type in your example has no name - it is anonymous.
The identifier boolean is the name of a field in mystruct.

This brings us to the heart of the matter. At the point where the enum type is created, we are no longer
defining names in the global ($unit) scope - names are now being declared within the struct's scope.
The BNF only imagines field names are being declared . But of course any anonymous types that
get declared are confined to this scope (won't be equivalent to similar types in other structs or in $unit).
This view comes from the C++ world where structs and classes are close relatives.
Were this an SV class declaration, you'd insist that the enum labels belong to the class scope.

Similarly, if the enum is declared in some named block nested elsewhere, you'd want its labels confined
to the nearest enclosing scope around the enum declaration.

It happens that a struct scope is especially limiting - there is a temptation to make a special rule
promoting these labels to some outer scope. But I find no such rule exception in the LRM.
 "NO" is not necessarily visible in mod1.

You might say that structs aren't scopes. But I can have two structs with the field name boolean
and they don't get a name duplication error, I just can't have two fields called boolean in the same
struct. "Scope" is an accurate description of these semantics. The question is whether and how
to apply it to incidental name declarations like the enum labels. The full answer impacts how these
names get resolved in any default value assignment made to this or other fields of the struct and
whether an enum value NO precludes having a field named NO, or if such a field name would eclipse
the enum value.

I think saying int a = mystruct :: NO; would be the right way to access this label.
I also think an enum type name should function as a scope for accessing its labels.

Greg Jaxon
Disclaimer: These are personal opinions, and do not reflect my employer's voting position or product commitments.

Rich, Dave wrote:
dhiRAj,

A enumerated type declares set of integral named constant members in the same scope that the enumerated type name exists. That is why you are not allowed to repeat the names in more than one enumerated type in the same scope, or re-use the name for any other identifier in the same scope. The identifiers (names) of an enumerated type have the same visibility rules of any other identifier.

Dave

From: owner-sv-bc@eda.org<mailto:owner-sv-bc@eda.org> [mailto:owner-sv-bc@eda.org] On Behalf Of Dhiraj Kumar Prasad
Sent: Friday, May 14, 2010 12:44 AM
To: sv-bc@server.eda.org<mailto:sv-bc@server.eda.org>
Cc: Surya Pratik Saha; Dhiraj Kumar Prasad
Subject: [sv-bc] Query related with the visibility of enum member.

Hello,

I have a query related with visibility of enum member.

For the following testcase

typedef struct {
            enum {NO,YES} boolean;
            }mystruct;

module mod1();

int a = NO;
endmodule

"NO" will be visible inside module ?? As some of the standard tools are passing while others
are showing error.

Regards,
dhiRAj

--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.
--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.
--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.