Pattern match on map keys that can be atoms or strings

I am a bit lost about which part of the code above comes from the library, and which is expected to be written by the user.

If you want run/1 to return something that would happily match to both %{foo: :bar} and %{"foo" => :bar}, it’s impossible (unless you override Kernel.=/2 which I would strongly rule out.)

Could you please clarify?

Only run/2 is the library function, everything else is written by the user.

Then I am not sure how were you going to “if the pattern match errored, catch it and use.”

Generally speaking, in such a case the approach would be to accept the options in a call to run/3 as for instance jason does.

# def run(name, options \\ [keys: :strings], fun)

%{foo: value} = run("do something", keys: :atoms, fn ->
  %{foo: "bar"}
end)

%{"foo" => value} = run("do something", keys: :strings, fn ->
  %{foo: "bar"}
end)

# the above is default
%{"foo" => value} = run("do something", fn ->
  %{foo: "bar"}
end)

Or simply document run/2 as returning binary keys always.

JSON is a very limited and is not 100% compatible with elixir terms.
If you want to use JSON, then you have to expose this internal detail to the end user, since you can’t convert {:ok, %{{:a, :b} => ~D[2021-01-01]}} to JSON and back without additional efforts. There will be some limitations and user should know about them.
So, I’d suggest adding an option to run/2, so the end user can specify which keys he’s interested in. Like this is done in Jason.decode/2 with :keys option.

Probably, the easiest way to receive the same data which user passes is by using :erlang.term_to_binary and :erlang.binary_to_term for serialization, instead of JSON.

Huh, didn’t thought about the options path.
That’s a good idea.

Then it’s possible to have configurable library defaults + specific overrides as well.
I think that works.
I should’ve mentioned this earlier, but the key thing is what is returned is what the user expects, so as long as the user have the controls to what they want, then it’d work for me.

Thanks a lot.

+1 to @fuelen’s point about JSON. There are a LOT of terms that won’t cleanly round-trip through that process, so you’d be better off explicitly documenting what will - or switching to a serialization format that’s higher-fidelity.

One warning is that if the data comes from an untrusted source, using binary_to_term is potentially dangerous as it is possible to define executable code inside of a data structure.

So now that I have a path forward with maps, I have a follow up question.
What if the returned object is a struct?

Syntax will look like this now.

%Foobar{foo: value} = run("do something", fn ->
  %Foobar{foo: "bar"}
end, opts)

This can be in any combination as well, since you can also do something like

%{foobar: %Foobar{foo: "bar"}}

When thinking in Golang or Rust, you can specify the return type of the anonymous function passed to run/2 (or run/3) as something like map[string]Foobar or maybe just Foobar.
This would actually simplify things if I have a target type to deserialize the data into.

Sample golang code will look like

type Foobar struct {
  foo string `json:"foo"`
}

foobar := &Foobar{} // instantiate a struct
err := json.Unmarshal(byt, &foobar) // deserialize the json bytes into the struct

Any ideas if there are ways to accomplish something similar in Elixir?

If the user implements the anonymous function passed to run, are they not in charge of what is returned? In which case they will know whether the function returns a map with string keys or atom keys because they implemented the function to do that? Or am I misunderstanding?