[snip]
>I agree, consistency is very important in the
>langauage. However, in the case of imports it pays to deviate from the
>consistency principle. It is far better to break consistency in this case
>because in doing so it provides an overall improvement on the language.

Isn't that principle obvious? The only question is does it improve the language overall.

>Even in "quick & dirty" programs, most of us here choose to import the modules that contain the functionalities we need rather that relying on their existence in some previously imported module. Bar none, this is the most prevalent cause of conflicts in D thus far. Yes we can avoid these confilcts with the use of "private import", aliases, and explicit access (e.g. std.somemoduale.somefunc()). But this is hardly an ideal.

To dig into the root cause of wanting private imports I'd like to find out where conflicts come from and how common they really are in practise. For me the conflict with Window came because I was creating a wrapper class around another class that was platform specific and one of the platforms happened to use the same name as the one I wanted. I'm guessing there are other examples that come from importing a phobos module and it happens to use a nice functionn name or something, but nothing springs to mind. It seems pretty rare that a set of names being used within one codebase would conflict.

I'm starting to convince myself the default should be "package" - or kept as public like everything else.

The only issue I have really with imports is the error message you get when you have a conflict doesn't give a clue about the import chain so you have to start digging around to find out who did the public import when they shouldn't have. When import chains get three or four deep with recursion it can get complicated to find the bug.

>An overwhelming amount of here would welcome this deviation.

uhh, for the record I don't care which way it is.

Ben Hinkle wrote:
>>I agree, consistency is very important in the
>>langauage. However, in the case of imports it pays to deviate from the
>>consistency principle. It is far better to break consistency in this case
>>because in doing so it provides an overall improvement on the language.
> 
> Isn't that principle obvious? The only question is does it improve the language overall.

The key question is not: "Which default is more practical for the programmer?", but: "What will the third-party libraries look like if we assume that many people stick with the default without thinking about the consequences?"

Exactly, but for that question, you will have to forecast where each decision might lead the language in the long term. Currently, libraries and packages are rather small and few. Of course, so far, conflicts are a rather rare event. To look further into the future of D, we can only try to learn from other languages.

One language that I'm using quite intensively at the moment is Python. One of my worst experiences here is to work with a mixture of numarray, Numeric, SciPy and matplotlib. These are four numerics packages that are developed by different groups but strongly interdependent. The packages import each other, modify details and reexport each other again. Basically, Python only knows public imports, meaning that many symbols can be imported via many different sources. Moreover, since the functinality is similar, many symbols are similar or identical. Now, if you know about a symbol "array", you will soon find out that each of the four packages exports "array". numarray and Numerics both define different classes by the symbol "array", so there clearly is a conflict. SciPy and matplotlib both reexport the symbol "array" coming from one of the former libraries. Of course, there are tools to sort this out, but at first, you definitely are confused.

There is no problem with conflicts: they can be solved in a similar way as in D. Still - if every module from a package exports a mixture of symbols from all kinds of sources, you completely loose track of the actual structure of the package.

(Same thing for C header files: once you include one, you get all kinds of symbols into your namespace. I you look at some random C file, the list of included headers would usually tell you nothing about what the file actually uses, but only give some selection of includes that happen to provide everything that is needed.)

What I have in mind for D would be something like: packages of interdependent modules. Each of them doing private imports from others and only exports a clearly defined, distinct set of symbols. In addition, there could be one "meta-module" that does not define any symbols itself, but just has a list of public imports of all modules in the package.

Now, if you use the package, you can decide whether you import some modules selectively or just do a import of the meta-module, getting all symbols.

Of course, this setup will be possible no matter what the default for imports is. Anyhow: it is clear from this picture that you would usually want to do private imports unless you have special needs.

Again, the key question is not: "Which default is more practical for the programmer?", but: "What will the third-party libraries look like if we assume that many people stick with the default without thinking about the consequences?"

[snip]
> What I have in mind for D would be something like: packages of interdependent modules. Each of them doing private imports from others and only exports a clearly defined, distinct set of symbols. In addition,
there
> could be one "meta-module" that does not define any symbols itself, but just has a list of public imports of all modules in the package.
>
> Now, if you use the package, you can decide whether you import some
modules
> selectively or just do a import of the meta-module, getting all symbols.

It is true that one can view declarations in a module as basically the opposite of importing a module. By declaring something you are telling the world about this new thing but with importing you are asking the world for something. So I can see how one could argue new users wouldn't be confused that a declaration is public by default but imports are private by default. It's like a yin/yang situation. Right now D is all yang and no yin. :-)

The other view is that import is adding declarations to the scope just without definitions so it's almost the same as declaring something and hence should be public by default.

I do agree though that default public will result in more potential conflicts - but will mean fewer imports at the top of files. Like in Java sometimes you get these import blocks at the tops of files with tons of imports and it just gets pretty annoying IMO.  I don't think Java has the concept of public/private imports - everything is private.

[snip]

Ben Hinkle wrote:
> The other view is that import is adding declarations to the scope just without definitions so it's almost the same as declaring something and hence should be public by default.

Exactly this "almost" is the problem. Of course, to the outside world, a native symbol and a publicly imported symbol look the same. But if this happens without care, suddenly every symbol seems to be part of every module, you loose track of the actual place of definition of symbols and the structure of a library gets blurry.

> I do agree though that default public will result in more potential conflicts - but will mean fewer imports at the top of files. Like in Java sometimes you get these import blocks at the tops of files with tons of imports and it just gets pretty annoying IMO.  I don't think Java has the concept of public/private imports - everything is private.

That's exactly the problem of Java. But in D we have public imports as well, so there is nobody hindering you wring meta-modules that only contain public imports. Each library could just have such meta-modules allowing you to import groups of modules at once. In an application, you could also have one central module that imports all the libraries that are needed and solves conflicts, so you just have to import this one module in every source file. Anyhow, such collections should be done deliberately and not just because people were too lazy to write the word "private".