Make imports private by default

[Sean Kelly]

Derek Parnell wrote:
> On Fri, 14 Apr 2006 12:06:08 +1000, Sean Kelly <sean at f4.ca> wrote:
> 
>> Derek Parnell wrote:
>>> On Fri, 14 Apr 2006 03:37:14 +1000, kris <foo at bar.com> wrote:
>>>
>>>>
>>>> In order to make D easy to learn and use, surely consistency in 
>>>> usage should be a priority? D kinda has that right now in this 
>>>> particular area, in that everything is public by default. It would 
>>>> also be fine, IMO, if everything were private by default :)
>>>  How many cars have rubber steering wheels? After all, the other 
>>> wheels are made of rubber and we do worship consistency?
>>
>> Oh come on, that's a false analogy.
> 
> Sorry. "the heat of the moment" and all that stuff ... don't know what 
> came over me.
> 
> I'm just not convinced yet that "consistency" is the highest design 
> priority. To me, "usability" is more important even if that means that 
> two things are not 'consistent'.

I use the term 'consistency' a lot, but a more appropriate term may be 
'predictability'.  Basically, I'm willing to bend on consistency so long 
as the result is still behavior that a novice would consider 
predictable.  That said, I prefer consistency here as the import 
metaphor isn't limited to just imports--it includes mixins as well.

As an aside, it would be really nice if there were a way to expose a 
single symbol from a privately imported module.  'alias' doesn't work 
because it will result in multiply defined symbol errors if both modules 
are imported by a third module.  This has come up a lot writing Posix 
headers because the bulk of them are required to expose one or two 
symbols from another header such as sys/types.  This can be accomplished 
with preprocessor language in C, but there's no way around publicly 
importing the entire parent module in D.


Sean