Callback modules in elixir are just a collection of callback functions. And callback functions even in other languages can do whatever they want to do. You can expect them to work a expected way (ducktyping) and you can document that expectation (e.g. type/behaviour specs) but there‘s no way to make sure they actually do adhere to those expectations.

The fact that modules can be added/loaded or even reloaded at runtime also make any compile time checks rather impossible in a generic way.

So long story short - this cannot be caught automatically. Fail loudly at runtime if the module or a callback breaks the expected contract.

Ultimately the assurances of statically typed languages cannot be given in a dynamic system, because the very system itself has the potential to change. So to reiterate what others have said, there isn’t really a way to achieve what you’re wanting to do, and most of the things that might seem to help give these guarantees, will only give you false confidence.

iex(28)> ABS.__info__(:attributes)[:behaviour]
[Car.Brake]

This might look promising at first, but it only really confirms that @behaviour Car.Brake is in the file, not that break/0 is.

iex(31)> ABS.break
** (UndefinedFunctionError) function ABS.break/0 is undefined or private
    ABS.break()

As others have said, you can make calls to function_exported?/3 to get more assurances, but ultimately these are runtime checks, and the question with all runtime checks should be “And what exactly do I plan to do if it’s not what it’s supposed to be?”. If you think the error message being thrown at Car.new/2 is a more helpful place for it to be raised rather than when NotReallyABrake.brake() is eventually called, then that might be a valid reason to do a check there, but I’m always personally quite against it.

Writing exception handling code now, in the hopes that it can, at some point in the future, diagnose and cure an unknown bug that I myself couldn’t avoid ending up in, is just setting myself up for almost certain disappointment, plus making the code more complex to boot. It’s almost always a lose-lose.

In the rare occurrences where I have something like this, I have in the past just added a guard:

def new(brand, brake) when brake in [ABS, BBS, etc.]

But only if there was a really valid reason to not just let invalid modules just crash naturally. Obviously with this approach you have another touch point you need to update if a new brake type is added, which forgetting to do so could itself introduce a bug(e.g. passing in a module that does correctly implement Car.Brake, but just wasn’t added to the guard list).

I think this is one of those static typing reassurances that just can’t be attained in a dynamic language without also bringing in all the other static language baggage. Remember that even though it’s not quite common place in Elixir, it’s possible for the very behaviour itself to change at runtime! So how can a compiler give you any assurances against a system which is completely malleable after the point which it would give those assurances.

Personally I would look at Behaviours as being suped up documentation with the added benefit of compile time warnings for the implementing module. So it can clearly state to someone seeing the module what this module is for and what it can do. And for someone writing a new module for a new Car.Brake type, it can make sure they have correctly implemented the callbacks as they’re currently defined. But not that Car.new/2 will always receive a module that implements that Behaviour. As far as I’ve seen, your @type brake_system :: module() typespec is the correct one to have there.

My understanding is that behaviours are normally used for contracts (like I am trying to achieve) while Protocols are normally used for data:

In my example, ABS and BBS are not data structures. They are modules which can perform complex actions (such as breaking to slow down a car). I personally do not think Protocols would fit this example properly.

As far as I know this is not possible.

The workaround in a functional programming language is to pass functions and not modules. But in Elixir we tend to use modules of that sort of things, mostly because passing each callback separately is not really practical.

What is the idiomatic way in elixir to specific that “module A” depends on an implementation of “behaviour B” ?

I don’t think that it is possible either. I’d really like a Dialyzer that supports behaviours but it is not the case. This is also why I do not like the pattern with injection used with Mox where you put the adapter in runtime config and have an adapter() function that returns the currently defined module. To me this should be a compile time thing.

In your case it is the same problem. I assume Car.WingsWithNoBreaks does not exist. But Dialyzer cannot even check that a module will exist or not when the module is passed dynamically.

Behaviours in Elixir are simply sets of function specifications (callbacks) that a module must implement. They should not be confused with Object-Oriented Programming concepts. Behaviours are not classes.

If you want to check whether a module fully implements a behaviour, you can verify that it provides all the callback functions defined by that behaviour. For example:

defmodule BehaviourChecker do
  def implements?(module) do
    callbacks = Brake.behaviour_info(:callbacks) || []

    Enum.all?(callbacks, fn {fun, arity} ->
      function_exported?(module, fun, arity)
    end)
  end
end

If you need to perform these checks at compile time, keep in mind that Elixir doesn’t offer robust static typing, which makes full static verification difficult. Depending on your requirements, you can use compile-time checks with macros, but comprehensive static analysis isn’t straightforward.