Discussion #1: Should we add map_get/2 and is_map_key/2 to Kernel?
No, it breaks the “only one way to do thing X” rule that won so much fans of Elixir and, partially, Go. That is still one of my top 5 favourite things about Elixir – the very minimal and expressive stdlib.
After reading some more though, I can see the value in adding them with the Erlang names. I suppose we will never get Map.fetch! and Map.has_key? allowed in guards? They can be replaced with the Erlang function calls when used in guards and thus we avoid the duplication Jose mentioned? Sorry if this is a naive suggestion, I am not aware of the realities of writing a compiler.
Not a strictly a fact, more like an opinion and a call for discussion if you are willing to entertain it: this is scratching and battering the gate between static and dynamic typing and since the BEAM has no ambitions to be statically typed, I’d say let’s skip it for now. I’m with @josevalim and @OvermindDL1 here: let’s expand and improve defguard instead.
Discussion #2: Should we allow patterns in defguard/1?
Yes. As @michalmuskala said, this might pose some performance problems but it seems they will be addressed in the future SoonEnough™. Famous last words I know, but I feel the feature is worth it. defguard is an amazing readability and productivity improvement mechanism and it should be developed further. The huge benefit is the smaller cognitive load: people need to limit parameter types or values, people know they have to turn to defguard or inline pattern matching for help.
Discussion #3: Should we allow map.field in guards?
Absolutely not. Many people come to Elixir from Ruby and Javascript, and they just expect certain syntax constructs to just work everywhere; they will be very disappointed when such a mechanism has only partial application and will probably leave. I am not saying we should strive for universal adoption or maximum users – if you follow my replies lately you’ll see I am actually against big growth – but less WTFs per minute and more explicitness should remain among the very top priorities of Elixir.
In my eyes, Elixir (and parts of modern JS) brought functional programming to the masses and the community should do its very best to keep it minimal yet very capable and thus average-programmer-friendly.
Maybe this third discussion should be resurrected in the future, if/when evolutionary changes in Erlang or Elixir make it relevant and feasible again, and without the compromises several people already outlined.
