Semantics of `using` with multiple modules in the same line.

[pauljurczak]

I don't see an example like this:

using Module1, Module2

in the documentation. Is it equivalent to:

using Module1
using Module2

or

using Module2
using Module1

or is the evaluation order undetermined?

[StefanKarpinski]

It's evaluated as using Module1; using Module2 but the order should not matter.

[pauljurczak]

It did matter for RobotOS package when some Python magic was performed. I was getting errors with:

using PyCall, RobotOS

but not with:

using RobotOS, PyCall

To be fair, when I try it now, after the pains of fixing Python environment, it works in both cases.

My main point was to see using Module1, Module2 somewhere in documentation. It would help a novice like me.

[yurivish]

It also matters with Revise.

[JeffBezanson]

Thus far using A, B has been equivalent to using A; using B. In the second case, we are forced to fully evaluate using A before using B; e.g. they might be in separate REPL inputs. But in the future, we probably want to be able to load packages in parallel when given using A, B. Ideally of course, using should not have side effects that make the order detectable. So I would document that using A, B is currently left-to-right, but that is implementation-defined and may change.

[tpapp]

document that using A, B is currently left-to-right, but that is implementation-defined and may

Incidentally, in

module Foo
using A
using B
end

is the order defined, or should we also leave that open for parallelization?

I am still not seeing the use case of depending on the order either in interactive use or in a module. If it matters for some package, I would suspect it is a bug.

[JeffBezanson]

That's a tough question, but I think they'd have to remain ordered. Reordering is generally an awkward fit for top-level expressions.

[PallHaraldsson]

The order matters (at least in theory, in practice in the most cases the end-result should be the same), but even on recent Julia 1.7 the order can take over a sec. off:

julia> @time @time using Stipple, JavaCall
┌ Warning: JavaCall needs the environment variable `JULIA_COPY_STACKS` to be `1` or `yes`.
│ Calling the JVM may result in undefined behavior.
└ @ JavaCall ~/.julia/packages/JavaCall/aVXyt/src/JavaCall.jl:53
  4.315682 seconds (5.92 M allocations: 361.579 MiB, 5.64% gc time, 0.16% compilation time)
  4.473595 seconds (5.98 M allocations: 365.422 MiB, 7.59% gc time, 0.16% compilation time)

julia> @time @time using JavaCall, Stipple
┌ Warning: JavaCall needs the environment variable `JULIA_COPY_STACKS` to be `1` or `yes`.
│ Calling the JVM may result in undefined behavior.
└ @ JavaCall ~/.julia/packages/JavaCall/aVXyt/src/JavaCall.jl:53
  3.112636 seconds (4.07 M allocations: 253.377 MiB, 3.96% gc time, 0.22% compilation time)
  3.172814 seconds (4.13 M allocations: 257.221 MiB, 3.88% gc time, 0.21% compilation time)

I observed this before, then experimented with many packages, and since there's a combinatorial explosion of orders, it would be nice to allow loading in parallel or best order.