As the driving author of the last major discussion about this
<https://groups.google.com/g/elixir-lang-core/c/P6VprVlRd6k/m/mbYKXr0zAgAJ>
on this mailing list (which ultimately resulted in implementing this macro
<https://github.com/christhekeele/tagged_tuple_shorthand>), I learned there
are 5 core things any proposal for field punning must either address or
dismiss to avoid re-treading ground:
1. How to handle atom and string keys
2. How to support maps and keyword lists
3. How to support the variable pinning operator
4. How to ensure visual clarity from other forms (ex, confusion with a
bare-words tuple {foo, bar} vs %{foo, bar})
Note that there are few extensible compromises here, as not including one
feature in the above tends to lead to a syntax that eliminates its
possibility in the future.
Since that conversation, I'd argue only 4. is any clearer since our last go
at this: as Zach points out, the type system can assist in catching typos
here now.
As a distant 5th concern, there is also the question of which syntax people
prefer (personally for me, bare-words a la JS, which seems to have grown in
popularity), but no syntax can be complete without navigating the above
concerns.
My personal argument for a JS-style "barewords" identifier over the
Ruby-symbol-syntax is that since it looks like a normal variable, it plays
visually well with support for the variable pinning operator if that is
added to the feature matrix.
--
You received this message because you are subscribed to the Google Groups
"elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/elixir-lang-core/496bbd8d-5d37-40c3-a140-5d1ea75b92cbn%40googlegroups.com.
