Re: [sv-bc] Is an unnamed block with declarations a scope?

>From: Greg Jaxon <Greg.Jaxon@synopsys.com>

>Is a named block a "declaration"?  If you put a named block inside
>an unnamed block, does the unnamed block become a "real scope" thereby
>making the named block and its contents inaccessible via hierarchical
>name?

Clearly not, if you read the context of my statement.  If you are
looking for formal wording for the LRM, it would have to be something
like "unnamed blocks with block_item_declarations".


>If you ever /do/ convert it into a scope - by, e.g., writing a
>for loop with a local index variable around the named block,
>or declaring some inconsequential temp variable - then the
>name binding to the block will jump down into that scope
>instead of staying up in the hierarchical naming tree as (3)
>seems to suggest.

Yes, but this is nothing new.  If you want to declare an inconsequential
temp variable in Verilog, you have to create a scope using a name,
after which the name binding to any nested named block will jump down
into that scope.  With (2), the only difference is that you don't have
to come up with an explicit name for the scope.  From what people have
said, that was the reason for adding this capability.


>Perhaps I slipped.  I think the first level name in any reference
>always resolves to the closest textually nested scope.  Disable
>statements and ordinary expressions employ the same rule.
>
>My answer to the "shadowing" problem goes like this:
>    A) A locally declared name can always shadow a more global meaning.
>       We could imagine a more restrictive rule to prevent some
>       kinds of shadowing, but I'd resist.
>
>    B) When a block name is to be bound in a scope global to the
>       currently active scope, it must be unique in ALL the unnamed
>       scopes up to and including the first named scope where it is
>       finally bound.

The obvious problem with this is that you now have a name that appears
in one scope, but pollutes the name space of other scopes where it does
not actually appear.  This has no precedent in Verilog, or any other
language I am familiar with.  Therefore it is confusing.

Also, since this situation is unprecedented, the terminology needed to
describe it probably won't fit into the existing specification of name
spaces, requiring it to be completely rewritten.  This may introduce
new errors in the specification.

Steven Sharp
sharp@cadence.com