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

Chat / Discussions
, , ,
1

I am returning to an Elixir project (finally!) after spending some (too much;) time in Python, and I am now curious about Elixir’s typespec notation.

Here is an example of a function definition in Python and in Elixir, with type hints / typespecs:

Python:

def is_admin(user_name: str) -> bool:
    ....

Elixir:

  @spec admin?(String.t()) :: boolean()
  def admin?(user_name) do
...

To my – admittedly, recently Python’ed – eye, the Python version seems a bit more elegant (and easier to read and to write) than the Elixir version. (Also, this might be the first time I am saying those words;).

I wonder

  1. how others in the Elixir community feel about this,
  2. how Elixir typespec notation came into existence (erlang-inspired?), and
  3. if there is an opportunity here for making the language even more delightful and user-friendly.

Wondering what folks think about this, and thank you!

2

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.

1 Like
3

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"
4 Likes
4

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.

1 Like
5

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

6

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

https://rocket-science.ru/hacking/2019/12/17/dialyzer-specs-2-in-1

1 Like
7

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.

1 Like
8

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"
1 Like
9

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.