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.