would be super useful. I know its been discussed to death years ago, but bringing it up again as I feel it would save a bunch LOC and readability issues, especially once your keys become like :table_animal_fur_color, :table_animal_paw_color, :table_animal_run_speed.
It doesn’t implement access since it isn’t a KV structure, you’d just say state in whitelist or similar. Unfortunately guard support is poor since it isn’t a true native structure. Maybe the latest OTP changes could actually improve that though with is_map_key, you could make some defguards.
I realize that something like this would be exceedingly rare in real code, but that fact of the matter is that it is still allowed by the Elixir compiler. If you, or anyone else, has an answer to this question, there may be a way to move forward with a proposal like this.
With that said, if you are trying to whitelist keys in your map, is there a reason you do not use a struct?
For anyone else that has not seen this kind of proposal before, here are a couple example conversations. I am sure there are others as well…
Already we assume itl be atom keys, because access.get only works on atoms. So ignore string keys.
Not whitelist keys in a map, but compare if fields are in a whitelist.
Like we gotta start doing more with maps these days, linked-lists (how erlang implements lists) are going the way of the dinosaur. They confuse modern CPU caching (due to pointer chasing) making them much slower in this generation of computing than other data structures. So like a Enum.find vs Map.get is like 10-20 times slower per member of the list, when you consider the pointer chase penalty.
" seems decidedly less readable than state in whitelist ."
Wish that syntax can work with maps as well.