markevans
Hi!
I’m excited about everything that’s going on re. gradual typing and am really pleased to see that Jose and the team seem to be thinking everything through extremely well.
I realise that it’s still all WIP and the $ syntax may never even make it in but I have one small thing that’s half question, half suggestion that I thought I’d raise…
All the literature I’ve seen up till now has parentheses after all the types, e.g.
binary(), integer(), float(), MyStruct.t(), etc.
Why is this?
I realise some types may have arguments, e.g. dynamic({:ok, term}), (would list(integer) be a thing?), but for the ones that don’t, would there be any harm of having the convention to leave out the parentheses?
I know it’s a small thing but personally I would find seeing code like
$ %{ user: User.t, age: integer } -> result
SO much easier to mentally parse than
$ %{ user: User.t(), age: integer() } -> result()
especially when there are other parentheses involved and as the statement gets more complex.
I don’t see why there would be any ambiguity because in the context of a $ statement I assume there are no variables as such?
I’m sure there’ll be a good reason but interested to know - thanks!
Where Next?
Trending in Proposals: Ideas
Other Trending Topics
Latest on Elixir Forum
Sponsor Spotlight
Build Elixir applications with speed and confidence.
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
- #elixir-ls
- #ai
- #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.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
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.
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 3- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
jvoegele
The one benefit that I can think of for always using parentheses after type names (other than just consistency) is that it makes it easy to distinguish between types and type variables.
markevans
Yes that’s a good point.
I’d hope that it would still be obvious what’s a type and what’s a type variable but it may not always be the case.
I guess it’s debatable which is more important out of consistency and readability and that may depend a lot on how complex the typical typespec is.
Typescript (which is also in some ways set-theoretic) doesn’t bother distinguishing between types and type variables, e.g.
type Blah = { /* */ }type Blah<Var> = { /* */ }though I’ve often seen/used the convention that type variables begin with a
T, i.e.type Blah<TVar> = { /* */ }venkatd
I like the suggestion to omit parens. I think most types in other languages don’t have parens unless they are parametrized.
It’s easier to read and write and we want the friction for writing types to be as low as possible
Plus there is already precedent in the Elixir language: macros that allow omitting parens to reduce noise.