josevalim
Hello everyone,
We had a discussion on elixir-lang-core about deprecating the use of ‘single quotes’ in Elixir for charlists.
The use of single quotes to specify something that looks like a string but isn’t a string is often a source confusion. This is specially frustrating given the expectation brought from other languages where double and single quoted strings can be used almost interchangeably. Therefore we plan to standardize on the already supported ~c[charlist] syntax instead of single quotes.
The plan is not to deprecate them now but rather in the long term:
- Elixir v1.4 will inspect ‘charlist’ as ~c[charlist]
- Elixir v1.6 will effectively deprecate ‘charlist’ (to emit warnings)
- Elixir v2.0 “who knows when” will remove single-quotes (to fail with syntax error)
However, before we move on, we would love if you could try using the ~c[abc] syntax in your codebase instead of 'abc' and report back your thoughts.
This post is not to discuss the deprecation of single quotes per-se but to collect feedback on the usage of ~c[charlist] in your own codebases. Please give it a try and let us know!
Where Next?
Trending in Notices
Other Trending Topics
Latest on Elixir Forum
Sponsor Spotlight
Deploy Phoenix to your own VPS with PaaS ease: push-to-deploy, zero downtime, auto SSL, managed Postgres. 14-day free trial at potions.io
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.
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.
Bringing learning, work and compliance together since 1987.
Producing high quality Elixir screencasts since 2017.
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 4- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
dimitarvp
That’s a very good idea and would clear confusion. Kudos.
Would you also consider adding another more specialized function and allow it in
case/cond/ etc.? I’m thinking about something likeis_charlist/1? Maybe addList.is_printable?/1as well? And allowis_charlist/List.is_printable?/String.is_printable?incase,cond,whenand friends?Or do you think it’s a better practice not to enforce these in
whenfunction declarations but to validate parameters in such a manner first thing in a function?Apologies for slight off-topic.
alxndr
This proposal seems to have been closed quite suddenly. Anyone have an update on why? The discussion thread on the elixir-lang-core group seems to be neutral-to-positive as well.
josevalim
Over the last weeks folks have been sending results and code samples of the experiment proposed on this thread with many cases where the code got considerably more verbose and less readable, such as integration with Erlang APIs, configurations that expect lists of char lists and so on. For those reasons, we have decided to avoid the change because, for such a big change, the core team should be at least 90% on board it is a positive change and we did not have such consensus anymore. Thanks for pinging back here, I forgot to update this thread.
alxndr
Thanks José!