Import concerns revisited

[John Reimer]

"Walter Bright" <newshound at digitalmars.com> wrote in message 
news:e93hja$1sfu$1 at digitaldaemon.com...
> 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.


Once again, the case was made based on C++.  That certainly makes it 
difficult to convince you any other way, and leaves a lot of non-C++ people 
incapable of ever making a strong argument for D changes.  You seem to have 
a strong attachment to the C++ community still.  There's a lot of peer 
pressure there, I guess?

Oh well, hopefully everything works out.

-JJR