josevalim
Replace 'charlist' by ~c[charlist] in your own codebases
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!
Trending in Notices
Other Trending Topics
Latest on Elixir Forum
Sponsor Spotlight
Producing high quality Elixir screencasts since 2017.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #elixirconf-us
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #metaprogramming
- #performance
- #security
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.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Practical resources that improve the lives of professional developers.
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!"
Most Liked
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.
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.
Last Post!
alxndr
Thanks José!