Import concerns revisited

[Derek Parnell]

On Tue, 11 Jul 2006 20:47:34 +1000, Walter Bright  
<newshound at digitalmars.com> wrote:

> xs0 wrote:
>>> The imports can be placed anywhere in the module, even (ugh) inside  
>>> class definitions. 'import' isn't any easier to search for than  
>>> 'alias'.
>> I was wondering - is there any good reason to allow imports everywhere?
> It's usually a good idea to make things as orthogonal, with as few  
> special case, as possible. Since imports are a declaration, they should  
> work wherever declarations work.


Does this mean you no longer mind imports inside a class definition,  
implying that the scope of the import is limited to the class members.


>> OT: if you'll be changing the import system, _PLEASE_ make private  
>> imports the default.
>
> It's too late for that, sorry. Also, everything else in D is public by  
> default, and consistency is sometimes better than special case rules,  
> even if those special case rules make some things easier.

Rubbish! All my import statements in modules that are meant to be imported  
themselves already have the 'private' attribute. This is just extra stuff  
that D is forcing me to use if I want clean APIs. The 'public' by default  
for imports (and anything else) is just causing me to do extra work to  
write safe code. I think it was a dumb decision and should be reversed  
before v1.0 is advertised. I have no code that would need changing 'cos I  
already use defensive coding. 'private' be default would make defensive  
coding just so much easier to do.

D has got so many things right that ugly warts like this stick out  
promenantly.

-- 
Derek Parnell
Melbourne, Australia