tsutsu
Why are the accessor functions in Access strict?
get_in and its related lensing macros have the “default” or “built-in” behavior (for Map keys, the only thing they support by default) of being forgiving when you attempt to navigate further from a non-existent key. For example:
iex> get_in(%{}, [:a, :b])
nil
However, none of the “accessor” functions in Access (Access.at/1, Access.elem/1, Access.all/0)—which, as far as I understand, only exist to be used in this set of lensing macros—“follow the lead” of the built-in behavior of these functions, in terms of how they handle navigating from a nil parent.
iex> get_in(%{}, [:a, Access.at(0), :b])
** (RuntimeError) Access.at/1 expected a list, got: nil
Is there a reason for this difference?
Is it necessary—e.g. can the modifying lens macros (put_in et al) not work with non-strict accessors for other types, the way they work with non-strict accesses of map keys?
Or could there be safe/non-strict variants of these accessor-fun-returning functions that do work this way? (I’ve written such variants myself, but only for get_in.)
Trending in Discussions
Other Trending Topics
Chat & Discussions>Discussions
Latest on Elixir Forum
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #elixirconf-us
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #metaprogramming
- #performance
- #security









