phcurado
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()}.
Where Next?
Trending in Discussions
Other Trending Topics
Latest on Elixir Forum
Sponsor Spotlight
Error tracking, logs, APM, uptime and cron monitoring in one dev-friendly platform. Find and fix problems before your users notice.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #ai
- #elixirconf-us
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Master modern tools, write cleaner code, and tackle real-world challenges.
Producing high quality Elixir screencasts since 2017.
**Building the future of software with AI, trust, and human connection.**
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 2- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
LostKobrakai
You noticed correctly that while there’s a
:atomliteral 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.
:atomon 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/OTPphcurado
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:
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
, but that’s only a guess.