I’m pretty sure you can just import the parent module of the __using__ macro with import A inside the macro. For example, the Phoenix 1.3 generators create the following DataCase module:

defmodule MyApp.DataCase do

  using do
    quote do
      ...

      import MyApp.DataCase
    end
  end

  def errors_on(changeset) ...
end

So, all of the MyApp.DataCase functions will be auto imported into the scope of any module which calls use MyApp.DataCase.

https://hexdocs.pm/elixir/Kernel.html#defoverridable/1 has an example similar to what you want:

defmodule A do
  defmacro __using__(_opts) do
    quote do
      def foo, do: "Foo"

      defoverridable [foo: 0]
    end
  end
end

defmodule B do
  use A

  def foo do
    super() <> "Bar"
  end
end

And then in the shell

iex(1)> B.foo()
"FooBar"

import makes the functions from A available in module B but it doesn’t re-export them. Therefore functions in B can invoke the imported functions from A but you can’t call them from outside B. Its nothing to do with use, its how import works.

Overall, your last example isn’t a strong justification for use. Just import would be preferred because the intent is clearer. But I recognise your use case if presumably more complex that just import.

I sort of understand your intent but, to me (and maybe only me), this smells a bit of “making magic”. And the language “inherit/extend” makes it seem even more so.

I’ve found that a combination of partial importing of functions and the occasional use of defdelegate is a lot clearer to me because its explicit. One of the most frustrating things is to see a function call to a function whose definition you can’t find. The multiple indirect usees would, for me, make the intent obscure and quite frustrating.