> Should the bang version really raise for redundant options?. If foo(opts) > wraps bar(opts) with extra options, foo() needs to clean up the opts before > passing them down [...] Maybe a non-bang version is the solution here. >
Correct. But I'd say that's what I would want from a bang function. I know this will lead to stricter APIs in some cases but those changes can be very helpful in some scenarios. For example, in Nx some APIs receive axis (singular) and other axes (plural) and raising on unknown options is important here. We could support a non-bang variant but it wouldn't be different from Keyword.merge/2 - so I am not sure of the value it gives besides consistency? > What do you think about supporting pattern matching? > If you need a Map, then calling Map.new afterwards is the way to go (and most likely the most efficient implementation). -- 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 elixir-lang-core+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4JitFpMDJ_3M1Uy%2BwE4KM%3DsscoL5G9uCTSLrYg049WiTA%40mail.gmail.com.
