Symbol lookup rules and imports

[ketmar via Digitalmars-d]

On Thu, 4 Dec 2014 14:15:22 -0800
"H. S. Teoh via Digitalmars-d" <digitalmars-d at puremagic.com> wrote:

> On Wed, Dec 03, 2014 at 02:10:52AM +0200, ketmar via Digitalmars-d wrote:
> > 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.
> 
> OTOH, Kenji has a different solution already in PR form:
> 
> 	https://github.com/D-Programming-Language/dmd/pull/3407
"Static, renamed, and selective imports are always public"? nononono!
as for static imports -- ok, let it be (but i don't want it too). as
for renamed and selective... in no way!
-------------- 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/20141205/24cb1d60/attachment.sig>