[Issue 3254] Module member visibility depends on declaration order

d-bugmail at puremagic.com d-bugmail at puremagic.com
Tue Aug 18 02:08:24 PDT 2009


--- Comment #3 from Stewart Gordon <smjg at iname.com>  2009-08-18 02:08:23 PDT ---
(In reply to comment #2)
> From bug 314
> > Access protection is defined to happen after lookup and overload resolution.

Defined where in the spec?

> So the correct behavior seems to match foo(int) first, then look for its access
> attribute. Though I don't understand this scheme too.

Basically, all overloads of a function name are looked at, regardless of their
protection attributes, in order to pick an overload.  Then the call is
validated on the protection attribute of the one that's been picked.

My guess is that the point is to protect against accidental behaviour changes
if some code is moved between modules.  But maybe it's better to avoid having a
private function and a public function with the same name in the same scope.

But the current behaviour does seem to be overdoing it.  If a module imports
two modules each of which defines a symbol, but in one of them it's private, an
import conflict is reported.  It's been my view for a while that private
symbols should not be imported at all.  Maybe the best policy is to see whether
_all_ overloads are private and, if so, the module will keep the symbol to
itself; otherwise, invoke the the current behaviour.

Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

More information about the Digitalmars-d-bugs mailing list