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:

  1. Elixir v1.4 will inspect ‘charlist’ as ~c[charlist]
  2. Elixir v1.6 will effectively deprecate ‘charlist’ (to emit warnings)
  3. 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!


That’s a very good idea and would clear confusion. Kudos. :slight_smile:

Would you also consider adding another more specialized function and allow it in case / cond / etc.? I’m thinking about something like is_charlist/1? Maybe add List.is_printable?/1 as well? And allow is_charlist / List.is_printable? / String.is_printable? in case, cond, when and friends?

Or do you think it’s a better practice not to enforce these in when function declarations but to validate parameters in such a manner first thing in a function?

Apologies for slight off-topic.

1 Like

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.

1 Like

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.


Thanks José!

1 Like