The challenge here isn’t really about creating charlists, the ~c sigil does that just fine. The issue is that if you have a value in your code and you IO.inspect that value, there is unavoidable ambiguity about whether to display it as a list of ints or a char list because there is no attribute in that value that says “I am a charlist”.
Sorta similar to %MapSet{map: %{}} I would love to see a hypothetical Elixir 2.0 deprecate raw charlists in favor of a ~c[abc] producing a %CharList{list: [97, 98, 99]} struct to skirt this problem entirely, reclaiming or deprecating 'charlist' literals, and resolving the display ambiguity entirely.
Elixir stdlibs could unpack the charlist.list where appropriate, and devs could interface with underlying erlang libs just as easily.
I guess I brought up something tangential. I’m specifically talking about the creation of charlists. What that resolves to when inspected I have no comment on
The main goal of charlists is Erlang compatibility. So we really should not change its representation. But charlist is already deprecate in Elixir v1.17 (main) and the formatter rewrites it since v1.15.
3 Likes
Hopefully not too tangential to the topic but I’m curious if there is a consensus style for handling charlists in custom inspect protocol implementations. Should it print the sigil, convert to single quotes, or something else?
I would say follow Elixir core if you are not sure what to do …
iex> inspect ~c"test"
"~c\"test\""
The custom inspect protocol implementations can use Any implementation to reuse a default Inspect logic.
1 Like
