DIP16: Transparently substitute module with package

Steven Schveighoffer schveiguy at yahoo.com
Thu Apr 5 07:43:42 PDT 2012


On Thu, 05 Apr 2012 10:35:52 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

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

Stop reading all my posts except for the ones I just posted.  I was  
completely wrong in what I thought the compiler couldn't do, because the  
spec is lacking.

I currently think DIP16 is invalid/worksforme (public imports allows  
splitting a module into a package).  All that is left is how we could  
specifically import a package with one import statement.

DIP15 covers that.  But I don't even think we need that, we can fix Phobos  
without any compiler changes.

-Steve


More information about the Digitalmars-d mailing list