Mixed Atom/String

[OvermindDL1]

Currently there is no way to have mixed atom/string representations. Any chance on having the default format (perhaps new sigil, M maybe) be something like:

~M(foo "bar" baz) = %{foo: 1, "bar" => 2, baz: 3}

foo # is 1
bar # is 2
baz # is 3

It would also be nice to be able to fallback to normal pattern matching for cases where the key is not easily turned into a variable, such as perhaps via:

~M(foo "bar" "a key"=>key 'complex-atom': an_atom_key 42=>a_num) = %{foo: 1, "bar" => 2, "a key" => 3, 'complex-atom': 4, 42 => 5}

foo # is 1
bar # is 2
key # is 3
an_atom_key # is 4
a_num # is 5

Or perhaps with commas?

Using some erlang code involves interesting mixed keys, not just string or atoms. :-)

[whatyouhide]

Hey @OvermindDL1, thanks for the issue!

I am 👎 on this for a few reasons:

• it makes the library more complicated and its scope larger: this library is pretty straightforward now: take this map with a very simple shape (e.g., strings to values or atoms to values where keys can be variables) and bind variables.
• it makes the library deviate from its original intent: the original intent was just to have syntactic sugar for very common cases such as matching on Phoenix params (string keys) or matching on structs (atom keys); this change would make it quite confusing in its goal, cause it would try to be a jack of all trades instead of a focused library.
• I don't believe these use cases are common enough. I almost never deal with maps with mixed string/atom keys, let alone "weird" atoms. If an Erlang library chooses to be a naming mess, it's that library's problem, we shouldn't make it easy to work with it (ideally, such libraries should be "punished" for bad behaviour somehow 😄).
• Small final note: the last example with the 'complex-atom' and everything looks like a bit of a mess IMO, I can't see the benefit over just matching on %{:foo => foo, "bar" => bar, "a key" => key ...} there.

Wdyt about this?

(Btw, closing this but feel free to reopen it if you feel my answer wasn't satisfying and want to keep the conversation going).

[OvermindDL1]

It is mostly an erlang library integration thing yeah, so can understand that, not a use-case most deal with. :-)