A failed "qualified" import produces a warning rather than an error

[nbaum]

Given

module Foo; end
import Foo.bar

the diagnostic WARNING: could not import Foo.bar into Main is displayed, but execution continues.

I'd expect an error - probably UndefVarError - to be signalled.

[vtjnash]

why is an error preferable?

[tkelman]

The import line was unable to accomplish the desired effect, seems to me like an error would be better.

[nbaum]

@vtjnash What @tkelman said.

1. The failure is probably unexpected. When I write import Foo.bar, my intention and expectation is that bar will be imported from Foo into the containing scope. Quoth the manual, "exceptions are thrown when an unexpected condition has occurred."
2. Failure is probably inevitable. Since I expect bar to exist after the import, and I probably wouldn't have imported it if I wasn't going to use it, my program will most likely not complete successfully if it isn't. There'll be an exception later anyway if I try to use bar but it doesn't exist. I'd rather get an exception at the point of the import, since that's where things first started to go wrong.
3. The failure might be disguised. If bar is a function and I define new methods on it after importing it, the exception finally raised might be a MethodError rather than an UndefVarError. If I didn't see the warning message, it might not be clear to me what the true cause of the problem is.

[StefanKarpinski]

An error seems better to me in this case. @JeffBezanson probably had something in mind here though...

[mghimirey]

This issue has been resolved. Now it throws the following error: ERROR: ArgumentError: Package Foo not found in current path:

• Run import Pkg; Pkg.add("Foo") to install the Foo package.

[fredrikekre]

The Julia 1.x equivalent to the OP is:

julia> module Foo end
Main.Foo

julia> import .Foo.bar
WARNING: could not import Foo.bar into Main

[Keno]

I put this on the strict mode list, but I think it's actually worth considering for syntax evolution. It can be useful to set up these sorts of bindings, but in that case you don't want the warning. Given that, I don't see any reason to not turn the surface syntax into an error in this case.