I don’t think you’re missing anything per se, but I wanted to add that using defdelegate creates a compile-time depdendency between the two modules which is good because it ensures that the module that you’re delegating too exists and has that function defined. And it is also bad since it may increase your compilation time or increase the amount of code that needs to be recompiled when you change a file.

But overall I like the clarity that defdelegate brings. It unambiguously shows that you are delegating the implementation of a function to this other function, and without changing any of the arguments.

Rest answered, that it is meant to provide nicer interface, but if you ask why, then let ask more:

• is |> necessary? You can always nest calls.
• is Enum module necessary? You can always use :lists and :maps modules.
• is in operator necessary? You can always use Enum.member? in body and comparison operators in guards.
• is if necessary? You can always use case.
• is with necessary? You can (and in old Elixir version you needed to) use case.

Etc. so as you can see this is just one of the nice sugar things provided by Elixir to simplify work.

Just adding to what @axelson said, I really like the property that it doesn’t change anything. For instance looking at benchee/lib/benchee.ex at main · bencheeorg/benchee · GitHub

There’s one public run function and then just a bunch of delegates:

    defdelegate init(), to: Benchee.Configuration
    defdelegate init(config), to: Benchee.Configuration
    defdelegate system(suite), to: Benchee.System
    defdelegate benchmark(suite, name, function), to: Benchee.Benchmark
    defdelegate benchmark(suite, name, function, printer), to: Benchee.Benchmark
    defdelegate collect(suite), to: Benchee.Benchmark
    defdelegate collect(suite, printer), to: Benchee.Benchmark
    defdelegate statistics(suite), to: Benchee.Statistics
    defdelegate load(suite), to: Benchee.ScenarioLoader

Makes it very clear that these are there for convenience and even links up the documentation