Qqwy
I am working on creating protocols, behaviours and implementations for multiple kinds of containers. (See Implement Containers for more info)
In many cases, the implementation is separated from the interface. However, it would be really nice if it were possible to write @specs that worked with a collection(/container/wrapper, etc.) containing certain datatypes.
For instance, there is the built-in type list(item). Now, item could be any (which is its default), but if a spec is written containing list(integer) and a non-integer is passed there, then Dialyzer will warn you.
So I’d like to do the same for other types of collection-like data structures. However, as the implementation is hidden from view from the behaviours and protocols, I cannot actually say anything about the internals of these data structures (Other than ‘it should implement this protocol’).
So I’d like to create symbolic wrapper types. Something like:
@type collection(item) :: type
(Using @opaque is probably better here, but that is beside the point.)
Above example will however not compile, as item is a free type variable which is not allowed:
== Compilation error in file lib/insertable.ex ==
** (CompileError) lib/insertable.ex:45: type variable item is only used once (is unbound)
(stdlib) lists.erl:1338: :lists.foreach/2
lib/insertable.ex:1: (file)
Is there a way to introduce item on the right hand side here? Or is there another way to create a type for wrapping-structures like queues, sets, trees etc that allows restricting what type of values should be inside?
Where Next?
Trending in Questions
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
- #elixirconf-us
- #blog-post
- #ai
- #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!
Practical resources that improve the lives of professional developers.
Bringing learning, work and compliance together since 1987.
The deployment platform built for Elixir: PaaS ease, VPS control.
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)
OvermindDL1
If you have any kind of
usecall to your module then you could build up the types in the remote module dynamically.If you are wanting to do something like an ‘unbound’ item that is to be filled in then I usually make an opaque
itemand use it, then have the other modules reference that type as it’s internal type (and/or refine it viause).What do you mean by introduce it on the right side? Can you show a complete example of what you ‘want’ it to look/act like?
(Or you could MLElixir that allows for types with arguments and refining. ^.^ /s)
Qqwy
@josevalim responded to me in the IRC channel, stating that Dialyzer cannot handle the dynamic protocol dispatch (at least as it currently stands), that creating specs for this probably wouldn’t really work.
So… I guess it is impossible, at least right now.