I can count on one hand the number of times when I wanted a list of printable ints to be shown as a charlist in the ~7 years I’ve been doing Elixir. Also in that time I’ve answered why it does that countless times to new people and in not one of those cases were they interacting with Erlang and needed it to be printed as text. I think the time has come to legitimately question whether this should still be the default given how easy it is to opt in to the behavior.

Love the change.

A thousand times yes, also for noobs trying to speak to erlang libs.

Amazing!

Definitely!

Personally I would like to vote for ~c(abc) instead. This would make many beginners think that ~c is “some kind of function”, so significant % of those should take a look at Kernel documentation at start before asking on forum/slack etc. sigil_c documentation would be then a “core/starting point of understanding the charlists”.

I believe we need to enhance said sigil_c documentation a lot. Even if it would not describes charlists in this @doc it still should point to a separate guide describing “what and why” is it.

I’d expect this to be a useful change. Raising the signal of differenciating binaries from charlists should be a net positive. Though I’m not sure about the use of double quotes as the sigil delimiters. They might be more confusing to people unaware of charlists, but I’d probably prefer them as someone aware of them.

I don’t think we can get rid of the need of being aware of charlists and what they are/how they work. So the best we can do is make people aware of them earlier, rather than later, at dev/built time, rather than in production. This change would support that.

I’d argue both are equally confusing. But I don’t think they’re equal in helping people to resolve that confusion.

To someone unaware of charlists and the fact that single quote are not interchangable with double quotes in elixir 'abc' doesn’t hold any signal of “this is something you don’t know about yet”. At best they wonder why there’s single quotes suddenly, but from my experience that doesn’t help much without knowing the significance of that. ~c"abc" on the other hand does hold more signal, even if the person might still wonder why there’s a sigil in front of the “string”. It hopefully leads them to learning about sigils (if unknown before) and sigil_c docs will lead them to learn about charlists.

Having provided explanations to many on slack as well as having tried to improve the documentation of charlists a few years ago I still feel like the most difficult part of explaining charlists is the fact that formatting a charlists as text is only a matter of representation of a list of integers, but it doesn’t mean it’s not a list of integers anymore. Using sigils hopefully makes this less mind bending, given other sigils are also used to represent a certain value via a different representation of it. ~D[2022-08-10] is a textual representation of a date struct, ~r/\d*/ defines a regex struct via its text format, …. At best people might have been in contact with sigils before, but given how many code challenges/katas/… accidentally produce charlists this is certainly nothing to rely on.

This is not a breaking change. Old code will still work fine, albeit with a warning, and effective support for single quotes would be removed only in 2.0, which would be several years from now (if it happens).