It is indeed a bit confusing.

Child specs (as in instances of the child_spec/0 type) require an :id value always.

However, writing a child spec by hand is error prone (not to mention a pain), and therefore there are functions to create/alter child specs for us: https://hexdocs.pm/elixir/Supervisor.html#child_spec/2 It is in fact for this function that :id values are optional (i.e. don’t have to be given to the overrides) and for which a default value will be given if absent.

In other words, calling Supervisor.child_spec({MyModule, [foo: :bar]}) will result in a child spec with id MyModule, whereas calling Supervisor.child_spec({MyModule, [foo: :bar]}, id: :my_id) will return a child spec with id :my_id.

If you want to learn more about Supervisors, child specs, etc. you may find my blog series on the subject to be worth a read: http://davidsulc.com/blog/2018/07/09/pooltoy-a-toy-process-pool-manager-in-elixir-1-6/ (especially “customizing the child spec” at http://davidsulc.com/blog/2018/07/10/pooltoy-a-toy-process-pool-manager-in-elixir-1-6-part-1-9/).

Granted I haven’t tried it that way, what does your child spec look like?

children = [
  # The Stack is a child started via Stack.start_link([:hello])
  %{
    id: Stack,
    start: {Stack, :start_link, [[:hello]]}
  }
]

Note that the above is equivalent to

children = [
  {Stack, [:hello]}
]

defaults to the given module

Given that phrasing I would try:

children = [
  %{
    start: {Stack, :start_link, [[:hello]]}
  }

Hypothetically the module could be taken from the :start value - whether or not that is happening I don’t know.

If that fails I have to wonder whether “defaults to the given module” actually refers to the tuple notation rather than the child spec map - as in “the module name will be also be used as the id”.

The other possibility is that it is trying to convey the convention of using the module name as the id for a singleton process (which is what the tuple notation is doing).