Import concerns revisited

[Walter Bright]

Don Clugston wrote:
> Walter Bright wrote:
>> 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.

If you write classes like:

	struct Point { int x, y; }

It's just irritating to have to write it:

	struct Point { public int x, y; }

Quite a lot of classes have all public members.

> 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.

That's a good point.

> (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').

Minor nit: 'export', not 'extern'.

> 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.

I think you've made a pretty good case for it.