I like to always expose a public function that has the same functionality as the protocol, but minus the generic runtime dispatch functionality as the protocol.

defmodule X do
  defstruct [:val]

  def new(n) when is_integer(n) do
    %__MODULE__{val: n}
  end

  defp wrap(n) do
    "the val is #{n}"
  end

  def to_s(%{val: n}) do
    wrap(n)
  end
end

defimpl Prot, for: X do
  def to_s(x) do
    X.to_s(x)
  end
end

This keeps the internals private, and also gives you a specialised function you can use for when you want to be a little clearer about what the value is.

Here the only thing the protocol definition does is register the type with the dispatch mechanism.

While I can see all of your mentioned pain points I don’t think they should be changed. The (primary) interface for a protocol is calling Prot.to_s not having a X.to_s. I’m not sure why you’d want to have X.wrap as a private function in the struct. Either you keep Prot and X independant, but then X needs to expose all the functionality Prot needs (publically) or you don’t and you can just implement Prot.to_s directly by moving the implementation of wrap into the protocol.

Elixir itself even goes so far in that DateTime.to_string and String.Chars.to_string(date_time) duplicate the implementation. The latter doesn’t call DateTime.to_string.

I’m not sure why you’d want to have X.wrap as a private function in the struct.

Well wrap is a (bad) example on how sometimes to providing an implementation for a protocol requires a deep knowledge of the data structure and usage of functions that we do not want to be exported.

But that makes me wonder if having protocol implementations to rely only on public functions should be a goal. I guess so for “tooling” protocols like String.Chars, Inspect or Jason.Encoder. But in the case of protocols used as pseudo interfaces to provide polymorphism (think MyApp.Storage with ETS, mnesia and Postgres adapters) then I would say that yes, X needs to expose all the functionality Prot needs publically.

Elixir itself even goes so far in that

Ok but those also are simple forward calls.

While I can see all of your mentioned pain points I don’t think they should be changed.

Acutally I agree, it is flexible as it is. But I wonder if it is common practice to just use defimpl as an indirection layer.

edit: And thanks!