@type representation for string maps

Chat / Discussions
1

I was checking the documentation for elixir and erlang types for ways to represent a map in the typespec.

I have seen different projects defining types for maps this way:

@type user :: %{
  required(:first_name) => binary(),
  optional(:last_name) => binary()
}

And this would be a valid “user” map that follows the typespec:

%{first_name: "John", last_name: "Doe"}

I could not find in the docs whats the proper way to represent a map with string keys. I tried to create a similar type from above using string keys instead of atom keys:

@type user :: %{
  required("first_name") => binary(),
  optional("last_name") => binary()
}

but this doesn’t compile, which is kinda expected considering the documentation is clear that it should follow the given format:

      | %{}                                   # empty map
      | %{key: value_type}                    # map with required key :key of value_type
      | %{key_type => value_type}             # map with required pairs of key_type and value_type
      | %{required(key_type) => value_type}   # map with required pairs of key_type and value_type
      | %{optional(key_type) => value_type}   # map with optional pairs of key_type and value_type

But feels like the language could offer some support for this type:

%{"key" => value_type}                    # map with required key "key" of value_type

So maps with string keys have better representation when defining the @type instead of fallback to map() or %{binary() => term()}.

2

You noticed correctly that while there’s a :atom literal type, there’s no counterpart for strings. binary() is the most concrete type supported. While I agree that supporting that would be a real boon to documentation using types the syntax for manual type definition is just the smallest part to your ask. The larger part is extending the typesystem and users of the typesystem (dialyzer) to handle that new more granular type.

I can’t say for sure, but I can imagine that this might even be quite a lot of effort. :atom on the beam become a lookup on the atom table, so they turn essentially to an integer. Whole binaries might be a lot harder for the typesystem to keep track of, especially larger ones.

However given dialyzer already “drops granularity” eventually when it starts to track complex data I’d be curious if that couldn’t be used as an argument for allowing the definition of individual binaries. Dialyzer could maybe treat too complex binaries as binary(). The latest otp release actually included changes to dialyzer for nominal types: Eep 0069 - Erlang/OTP

1 Like
3

Thanks @LostKobrakai, great insights and the EEP-0069 link was a good read.
I guess the closest type I can express the string maps would be:

%{required(String.t()) => term()}

Considering the limitations you mentioned, which would require some big effort to support it.

I think with the new type system for Elixir (which will not use Erlang’s types AFAIK), may introduce ways to express better the type for string maps :crossed_fingers:, but that’s only a guess.