Import concerns revisited

[Don Clugston]

Walter Bright wrote:
> Lars Ivar Igesund wrote:
>> Walter Bright wrote:
>>
>>> Lars Ivar Igesund wrote:
>>>> Well, who did ever say that was a good idea, everything public by
>>>> default? ;)
>>> I did <g>.
>>
>> Right :) I don't agree.
> 
> Let me explain why I think default public is a good idea.
> 
> It reduces clutter in sample, example, and quick programs. Access 
> security is an advanced feature, one that's invaluable for a complex 
> project, but is just in the way for smaller ones.
> 
> I don't mind at all when crafting a carefully designed, reusable module 
> that 'private' needs to be explicit. It helps document the intention, 
> and lends the impression that the designer did put some thought into the 
> code.
> 
> But when writing illustrative sample code, I feel that having to add in 
> 'public's is distracting from the point (unless, of course, the point is 
> about how access control works!). I see this a lot in sample C++ code, 
> and it is distracting, to me anyway.
> 
> And it's just plain irritating when writing smaller programs where 
> access control is quite irrelevant.

I agree. An interesting example is that many small classes in C++ STL 
programs use 'struct' instead of 'class' because it defaults to public.
You can find 'struct' all over the Boost libraries! Default public must 
be worth something.

But I don't think this argument is applicable to imports.
(a) For quick and dirty programs, and for most examples, you don't care 
if imports are public or not.
(b) Since a module exists in its own file, I don't think the consistency 
argument carries much weight. Functions in an executable file or DLL are 
only public if you add 'extern' to them (the program as a whole defaults 
to 'private'). For modules, we're talking about 'default transitory 
public' which I think is quite different to 'default public'. I can see 
over my neighbours fence, but that doesn't mean I can see over *his* 
neighbours fence (even though he can).

Changing to default private would break code, but it might not break a 
whole lot of existing code.
(a) I suspect that the majority of quick and dirty imports don't 
actually care if they are public or private. It's not as if every 
existing instance of 'import' would need to be changed to 'public import'.
(b) Some existing broken code would be fixed! I keep finding I need to 
put 'private' in front of 'import' in existing modules, to solve name 
conflicts.

And any code that would break could be fixed very quickly.

Please consider this issue again. There is still a window to change it 
before 1.0.