RE: [sv-bc] Mantis 2674 and 2611 (ballot 123 and 131)

 
I concur with Gordon. We do not want to treat type names differently
than variable names.

Francoise
    '
-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
Gordon Vreugdenhil
Sent: Monday, April 27, 2009 8:05 PM
To: Greg Jaxon
Cc: SV_BC List
Subject: Re: [sv-bc] Mantis 2674 and 2611 (ballot 123 and 131)

I don't like this change.  The issue is that one would have to NOT
report "C::x" as an error if "C"
was a variable and package "C" also exists.  And what about if there is
an inner variable "C" and a further out type "C"?  Do we then bypass
just the variable or is the existence of an *earliest* lexical binding
as a non-type sufficient to look for a package?

Since this is pure lexical scoping, I don't think this is a huge name
conflict issue and I don't like the additional complexity of what you
are suggesting.  I'd prefer to keep the rule a bit more tight at this
point; we can relax it in the future if there is sufficient push-back
that the more restrictive form causes real problems.

Gord.

Greg Jaxon wrote:
> Gordon Vreugdenhil wrote:
>> Mantis 2674 (fopen filename) and 2611 (package/class :: prefix
>> binding) have proposals in Mantis.
>>      http://www.eda-stds.org/mantis/view.php?id=2674
>>      http://www.eda-stds.org/mantis/view.php?id=2611
>>> If the prefix name is resolved using the normal scope resolution 
>>> rules, the '::' shall denote the class resolution operator. 
>>> Otherwise the '::' shall denote the package resolution operator.
> Based on our earlier exchanges on this subject, I have to 
> counter-propose this rewording of Sect 23.7.1:
> 
> If the left operand of the scope resolution operator :: resolves via 
> the normal scope resolution rules *to a name previously declared as a 
> type*, it shall denote the class scope resolution operator (see 8.22).
> Otherwise the '::' shall denote the package resolution operator.
> 
> Text in 8.22 could, but need not change to clarify this.
> 
> I feel there is at least a human factors reason to not let data names 
> shadow package names: there are just too many places you need to look 
> to track down a collision with a data name, there are far fewer ways 
> to declare type names.
> 
> Greg Jaxon
> 

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


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.