Keyword.validate will accept just a keyword, right? Did you consider
making it accept any enumerable of pairs, just like Keyword.new does?
Same for Map.

I think one particular scenario is something like this:

    def foo(opts) when is_list(opts) do
      config = Map.validate!(opts, …)
      config.name # the assertive map.key is really convenient here

what do you think? The only concern, besides feature creep :), is
perhaps validate is not the best name given it accepts broader set of
inputs. But then again, Keyword.keyword and in particular Map.map are
maybe a bit awkward. 

On July 26, 2021, josevalim <jose.va...@gmail.com> wrote:
> I debated this with the Elixir team and we agreed on the following
> API:
>     Keyword.validate! :: keyword | no_return    Keyword.validate ::
> {:ok, keyword} | {:error, unknown_keys, missing_keys}
> The same functionality would have to be defined for Map.
> The API for Keyword.validate! and Map.validate! would be the exact
> same as the one found in Nx.Defn.Kernel.keyword!.
> Could you please send a PR? Or open up an issue if you can't submit it
> at the moment. 
> Thanks!On Monday, July 12, 2021 at 12:46:38 PM UTC+2
> polva...@gmail.com wrote:

> > I would propose to add this to the Kernel module, to mirror the
> struct! helper. But adding to Keyword also works. Thoughts?
>
> Makes sense! I suggested Keyword mostly because there's the module
> already, but since we have struct! in Kernel, it might be better to
> have keyword! there too. Usage would also be nicer this way.
>
> > Should the bang version really raise for redundant options?
>
> As José said, it would help clean out stray options being passed. I
> can think of a few cases in which I thought one option was being used,
> but had either a typo or wrong name altogether (think "end" vs
> "end_datetime" sort of situation).
> However, I can see a less strict version being useful as well. Perhaps
> there could be a keyword!/3 which accepted options like:
> keyword!(opts, [extra_keys: true], key1: :default1, key2: :default2)
>
>

>  --
>  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
> <mailto:elixir-lang-core+unsubscr...@googlegroups.com>.
>  To view this discussion on the web visit
> https://groups.google.com/d/msgid/elixir-lang-core/9b83a803-c2c1-49e7-
> a531-56791607bcaan%40googlegroups.com
> <https://groups.google.com/d/msgid/elixir-lang-core/9b83a803-c2c1-
> 49e7-a531-
> 56791607bcaan%40googlegroups.com?utm_medium=email&utm_source=footer>.

-- 
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/42af0ffe5f534b75bfaa6f3d2aecaea93295725c%40hey.com.

Reply via email to