Do you ever `import` inside a function?

Chat / Discussions
1

From the docs on import:

Note that import is lexically scoped too. This means that we can import specific macros or functions inside function definitions:

defmodule Math do
  def some_function do
    import List, only: [duplicate: 2]
    duplicate(:ok, 10)
  end
end

In the example above, the imported List.duplicate/2 is only visible within that specific function. duplicate/2 won’t be available in any other function in that module (or any other module for that matter).

The example given is silly; it’s shorter and clearer to call List.duplicate(:ok, 10). But you have to import Ecto.Query to use its macros. I’ve used a function-local import when only one function in a module needs import Ecto.Query, but it’s been flagged in code review.

When, if ever, would you use import this way?

2 Likes
2

Sometimes in a test helper in a test file I import Ecto.Query because that function is the only place where we will interact with the DB.

3 Likes
3

I absolutely would and have used import Ecto.Query inside a single function, a good amount of times. Trouble is that many don’t like it for reasons they can’t explain very well themselves and deny a PR approval until the import is extracted top-side.

I partially get their point: if you get to a point where tracking the source of an imported function becomes difficult then that obviously means you should break your module apart on several smaller ones. I am a huge fan of such incremental refactorings.

But IMO some of the import-s (when not using :only) can bring in quite a lot of context that might be surprising or lead to weird compile-time warnings and runtime errors if f.ex. you import two modules and they have overlapping function names. For those cases either use :only religiously or, like you are demonstrating here – just limit the scope of the import.

It’s a very valid technique IMO. Though nowadays I lean to using :only or reducing the sizes of modules / functions more than reaching for lexically scoped import.

4 Likes
4

There’s also more more parts to lexical scopes than just function definitions. E.g. you could do an import outside of a module definition and it would affect the whole file, you could have an import within an anonymous function and it would only apply to that function, …

Personally like people before I’d also argue having a single function do an import can be perfectly fine.

2 Likes
5

Consider as well libraries that (judiciously) override kernel functions, for example: Image’s Math module.

I’m all for importing inside functions in scenarios like you describe and even importing just above the function where it is first used. Any push back is very much a “this is the way we’ve always done it” scenario (angry monkeys!). It makes no sense to me that you would want to spread these things apart. Same goes for mandating that module attributes must be at the top and that private functions must be at the bottom.

I never considered this and could have come in handy in some code I no longer work in :slight_smile:

1 Like