[dmd-beta] dmd 2.063 beta 3

[Nick Sabalausky]

On Sat, 18 May 2013 15:20:58 -0700
Jonathan M Davis <jmdavisProg at gmx.com> wrote:

> On Saturday, May 18, 2013 22:30:30 Rainer Schuetze wrote:
> > I think the new behaviour is consistent with symbol lookup rules,
> > but I'm not so sure about import rules. The actual case that
> > triggered the issue was with the base class in a different file.
> > Usually non-public imports in a module don't have an effect on
> > another module that imports the module. In this case it has.
> 
> I would argue that the import would need to be _protected_ in order
> for derived classes to be affected by it if they're not in the same
> file. Having a private import affect something outside of the file
> that it's in violates the access rules.
> 

I think that's a reasonable way of looking at it. Private imports
inside a class should naturally *be* private.

> 
> It
> seems _much_ cleaner to me to just restrict local imports to lexical
> scope, and I don't see how that would be inconsistent or surprising
> given that they're import statements, not symbols.
> 

I also have always thought of imports as being a "lexical scope" thing.
(FWIW).

> 
> I would then strongly
> argue that using class-level imports is bad practice and that if you
> need the import that much, it should be a top-level import.

I think that would be a common sentiment. At least, I know I'd be doing
the same. *Even without* the risk of function hijacking, it just
seems very messy: Private imports should never have any affect
outside the current module (Or for that matter, the current lexical
scope.)

Like you, I can live with it as well (provided there's no chance of
hijacking), but the current 2.063 beta's behavior definitely does not
win on the "simplicity" and "consistency" fronts.