Can has? `def admin?(user_id: String.t()) :: boolean do`

Mostly I just wish that Elixir were statically typed. Other than that, I’d probably prefer inline type annotations as opposed to separate function specifications.

The specification keywords seem mostly fine and unsurprising even if slightly more verbose than in some other languages.

Admittedly, String.t() is the one thing that seems a little awkward, but there is a reason it ended up that way and, as you might imagine, you’ll likely forget it bothers you at some point.

Timely post for me as I just spent a while annotating a bunch of functions with typespecs. I’m not sure it’s my preference overall but I like the separate vs inline specs in Elixir because of function overloading and pattern matching on function defs. So if you have a function that takes an integer and does some computation based on the value of that integer you don’t need to repeat the spec for each def.

@spec foo(integer()) :: String.t()
def foo(1), do: "one"
def foo(2), do: "two"
def foo(_), do: "I'm tired"

If I am not mistaken typespecs were a later addition to Erlang and the idea way to not to have to change the language syntax, that is way it all resides in a module attribute.

If you use the type string() (which means a charlist) you will get a warning, you can use binary() instead (@baldwindavid shared a link about this). But String.t() means it is UTF-8.

This is a great example for why a separate typespec is useful, thank you.

You can always achieve the custom python-like (or whatever else-like) syntax with a bit of metaprogramming.

I’ve also found that typed function signatures in Python get noisy. And the default formatter… does not make that look elegant. I like the separate type signature in Elixir, even though that often gets a little noisy, but it’s miles better.

Not necessarily. You could define a function head, which sometimes is needed in Elixir and define it the way you do in Python had Elixir supported such feature. Actually it is needed in the example given by @stevensonmt, otherwise your documentation will look like foo(arg1)

So you define your function head like:

@spec foo(integer()) :: String.t()
def foo(integer)
def foo(1), do: "one"

I have a strong preference for type annotations to not be inlined: they are useful, but most of the time add noise. For example, it’s pretty obvious what the type is for the first function argument because of how Elixir code is organized (dedicated modules and pipe-friendliness).

When I’m looking at the docs, I somewhat follow this order:

• Function head,
• Examples,
• @spec
• @doc,
• @moduledoc.