Import proposals (Ideas)

Dave Dave_member at pathlink.com
Mon Jul 10 12:12:04 PDT 2006


Oskar Linde wrote:
> 2 comments:
> 
> Dave skrev:
>> Regan Heath wrote:
>>> Sub-thread for ideas.
>>
>> My preference for syntax and semantics would be:
>>
>> // regular import w/ optional alias (*)
>> import std.stdio, std.c.stdlib as stdlib, std.date;
>>
>> // symbol specific lookup w/ optional alias (**)
>> import from std.stdio writef, writefln as print, readf;
> 
> How would the parser disambiguate the import of the module readf from 
> the symbol readf in std.stdio?

Great questions <g>

Assuming just the import from above, it wouldn't have to. Assuming 
std.stdio was imported in toto somwhere else, I would say that the 
specific import would then take precedence.

For example,

import std.stdio;
import std.mystdio; // also contains implements writefln
import from std.stdio writefln;
void main()
{
writefln("Always uses writefln from the 3rd import statement.");
std.mystdio.writefln("Unless an FQN is used.");
std.stdio.writefln("Same here.");
}

Because the whole point is to specifically disambiguate the writefln 
from the third import statement.

If the writefln from the 3rd statement was then considered part of the 
current namespace (module) as I believe was mentioned in the original 
threads, then this should not be a problem for the current compiler 
implementation either, because the innermost namespace takes precedence 
for lookup when an FQN is not used and there is a 'conflict'.

> 
>> // combined
>> import std.stdio, from std.thread wait as wait, pause, std.date as date;
>>
>> * Importing an entire module as an alias would then require a FQN to 
>> access any of the members, for example given the above:
>> malloc(...); // error
>> std.c.stdlib.malloc(...); // error
>> stdlib.malloc(...); // Ok
>>
>> ** A specific symbol that was not aliased would require a FQN to 
>> access. For example from above:
>> std.stdio.writef(...);
> 
> Just to clarify, does this mean that to import std.c.stdlib as FQN only, 
> you would have to do:
> 
> import std.c.stdlib as std.c.stdlib; //(1)
> 

No, that would cause a conflict with the way alias works already because 
you can't:

alias std.c.stdlib std.c.stdlib;

I would say then that the coder would just FQN everything themselves 
(even though it's not required by the compiler) or come up with an alias 
like:

import std.c.stdlib as std_c_stdlib;

I'm trying to make this all implementable with what's aleady in the 
compiler except for how the new import syntax is processed, and be 
backward compatible with the current import statement.

> Or, indirectly:
> 
> import from std.c.stdlib a_symbol_I_will_never_use;
> 

That would limit the imports from std.c.stdlib to 
'a_symbol_I_will_never_use' (unless other import statements imported 
other symbols from std.c.stdlib of course). So, if the specific symbol 
'a_symbol_I_will_never_use' wasn't ever used, the import statement would 
be superfluous.

> ?
> 
> 1) When you import something as fqn-only, you must be ok with typing out 
> the full name quite a lot, so once more will not make much of a 
> difference I guess...
> 
> /Oskar



More information about the Digitalmars-d mailing list