Global imports

[Acmion]

A global import statement could provide various benefits to Julia. Consider the following:

Main.jl

import Module1
import Module2

m1 = Module1.some_function()
m2 = Module2.some_function()

include("Project.jl")

Project.jl

module Project
    function do_something()
        return Module1.some_function() + 1
    end
end

Executing Main.jl would throw an error at the inclusion of Project.jl, becuase the module Module1 is not imported in the file.

Introducing a new syntax global import (or equivalent) the code above could work and would provide benefits. In fact, the modules Core and Base can almost be considered as global imports, since they are implicitly imported into each module (not counting baremodule).

This is not a new feature and has been implemented in several other languages or frameworks, for example, ASP.NET Core MVC utilizes global imports with special _ViewImports.cs. This feature has also been proposed for general use in C# 10. You can see the discussion about that here: dotnet/csharplang#3428. The feature has now been moved from a "candidate" to a "working set" proposal.

[JeffBezanson]

You can see the discussion about that here: #28789.

Did you intend to link to a C# issue? Please paste the full link if so.

I find it surprising that this would be considered a good idea. Isn't it better for each piece of code to declare its dependencies? Is there a killer example of when this is useful?

[vtjnash]

This could perhaps be expressed via something like Reexport.jl. Or something reversed of that? Perhaps you could write export MyFunctions, OtherModule.export, Module2.export to re-export the contents of those modules. Or perhaps with export using Foo. Or perhaps it would be Foo that declares certain exports are automatically re-exported when doing using Foo?

[Acmion]

@JeffBezanson

Did you intend to link to a C# issue? Please paste the full link if so.

Thanks for the remark about the link! Didn't realize I pasted in the wrong link. Fixed it now.

I find it surprising that this would be considered a good idea. Isn't it better for each piece of code to declare its dependencies?

I do not find that "global imports" in ASP.NET Core make the code any less readable. Actually, the "global imports" in ASP.NET Core are always inherited downwards and so the imports locations are clear depending on a file's location in the file system. One

One way to go about it would be to define a specific "Imports.jl" file that would then act as the global import file.

Is there a killer example of when this is useful?

I do consider the ASP.NET Core MVC _ViewImports.cs a killer feature. Once you get acquainted with it, you won't go back. However, it is difficult to explain it without trying it for yourself. The main C# language has also seen some benefits in this approach, although I am not certain what their specific motivations were.

[Acmion]

@vtjnash

This could perhaps be expressed via something like Reexport.jl. Or something reversed of that? Perhaps you could write export MyFunctions, OtherModule.export, Module2.export to re-export the contents of those modules. Or perhaps with export using Foo. Or perhaps it would be Foo that declares certain exports are automatically re-exported when doing using Foo?

This does somewhat touch the same issues as global imports, but there would still be the extra boilerplate. Nice find anyway!

[GeorgeS2019]

It seems this is the latest effort to provide .NET wrapper

Other related issue
Other WIP .NET c# csharp wrapper projects:

• JuliaSharp

[vtjnash]

This doesn't seem like something we are likely to add, and could be converted to a discussion, or moved to discourse.