January 09
On Wed, 09 Jan 2019 22:59:59 +0000, Dgame wrote:
> Maybe I'm missing something, but wouldn't it be possible to lazy import `import foo;` if the compiler checks lazily if a symbol isn't found in the current scope and only then tries to find it in one of the imports? Or would that be ineffective?

If you import two modules and both define functions named `write`, it is an error to use that function without somehow disambiguating. With every module import being lazy, it would only be an error if you had previously used symbols from both of those modules, and otherwise you'd get the function from whichever module has already been loaded.
January 10
On Wednesday, 9 January 2019 at 23:14:09 UTC, Neia Neutuladh wrote:
> On Wed, 09 Jan 2019 22:59:59 +0000, Dgame wrote:
>> Maybe I'm missing something, but wouldn't it be possible to lazy import `import foo;` if the compiler checks lazily if a symbol isn't found in the current scope and only then tries to find it in one of the imports? Or would that be ineffective?
>
> If you import two modules and both define functions named `write`, it is an error to use that function without somehow disambiguating. With every module import being lazy, it would only be an error if you had previously used symbols from both of those modules, and otherwise you'd get the function from whichever module has already been loaded.

That's right.  Basically it boils down to this, as soon as you need to resolve the first symbol that isn't defined in the current module, you now have to load "ALL NORMAL IMPORTS" in the current scope;

import foo, bar, baz;

void func1() { }

func1(); // don't need to import any modules
func2(); // now you need to load all normal imports, foo, bar and baz.
         // even if you find func2 in the first module, you still have
         // to load them all because they could both define it and they
         // may either be ambiguous or one may have an overload that
         // matches better.  plus, you have to load them all in order to
         // keep module order "invariant".



Next ›   Last »
1 2 3 4 5