Symbol lookup rules and imports

ketmar via Digitalmars-d digitalmars-d at puremagic.com
Tue Dec 2 16:10:52 PST 2014


On Tue, 2 Dec 2014 15:55:34 -0800
"H. S. Teoh via Digitalmars-d" <digitalmars-d at puremagic.com> wrote:

> Hmm... actually, this gives me an idea. What if we implement a little
> syntactic sugar for this in the compiler? Say:
> 
> 	scope import std.conv ... ;
> 	scope import std.format ... ;
> 
> gets lowered to:
> 
> 	private static struct __imports {
> 		import std.conv ... ;
> 		import std.format ... ;
> 	}
> 
> where __imports is an implicit nested struct that gets introduced to
> each scope that uses "scope import".
> 
> Then we introduce a new lookup rule, that if a symbol X cannot be found
> with the current lookup rules, then the compiler should try searching
> for __imports.X in the current scope instead. That is to say, if:
> 
> 	format("%s", ...);
> 
> cannot be resolved, then pretend that the user has written:
> 
> 	__imports.format("%s", ...);
> 
> instead. Sortof like the import analogue of UFCS (if a member function
> can't be found in a call obj.method(), then look for method(obj) in the
> global scope instead).
> 
> This way, existing code won't have to change, no breakage will be
> introduced, and only a small addition (not change) needs to be made to
> the existing lookup rules. Then whenever we need "use" semantics as
> opposed to raw "import" semantics, we just write "scope import" instead,
> and it should all work. (So we hope.)
> 
> Heh, sounds like DIP material...
i think that this is a great idea! i already love it.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20141203/13a1c14c/attachment.sig>


More information about the Digitalmars-d mailing list