DIP16: Transparently substitute module with package

[deadalnix]

Le 05/04/2012 16:35, Andrei Alexandrescu a écrit :
> On 4/4/12 10:53 AM, Steven Schveighoffer wrote:
>> On Wed, 04 Apr 2012 12:33:26 -0400, Michel Fortin
>> <michel.fortin at michelf.com> wrote:
>>> Question 2: does std.algorithm.sort refer to the std.algorithm.sort
>>> *module* or to std.algorithm.package.sort *function* publicly imported
>>> from the std.algorithm.sort module?
>>
>> The function. A symbol that is not specified as the module name in
>> import statement or in a module statement is always *not* a module. I
>> think our one saving grace here is that when you want to import a
>> specific symbol from a module, this is not the syntax:
>>
>> import std.stdio.writefln;
>>
>> So there is never any ambiguity as to whether you mean a module
>> identifier or other symbol.
>
> Interesting. But isn't there an ambiguity when the symbol is not the
> last one in the chain? Consider:
>
> a.b.c.x
>
> Could be static member d of class c in module a.b, or module member d in
> module a.b.c.
>
>
> Andrei

The whole point of this thread is to import symbols from submodules into 
a module. Obviously, this tends to create collisions. This one is hard 
to solve and should probably be an error.

However, such a collision will also appear with DIP16, and DIP16 cause 
also other type of collisions. So that one is superior - even if not perfect