Thanks, José. I agree with the need to be consistent. I will look at the bigger
picture, though, like Manfred I find the addition of "maybe" to be awkward, so
my preference is to have the existing recommended functions in the Access
module intended for use with get_in to be consistently nil
I think that optionals, like maybe should have a very good reason.
Usually it’s either there or not. There is no maybe.
So I would rather return nil, which represents that a value is not there.
Something like:
Access.at(0) |> Access.maybe
looks quite awkward.
Just my two cents,
Manfred
> Am
The proposal is reasonable however it would introduce an inconsistency
since the other selectors in Access, such as Access.key, are also not nil
safe. So whatever solution we choose needs to be consistent.
One possible suggestion is to introduce a "Access.maybe" that composes but
composition
I propose that the function returned from Access.at/1 special case nil such
that the overall Kernel.get_in/2 call returns nil instead of raising an error.
Rationale:
I originally blamed this on Kernel.get_in/2 and I'd like to thank Eric
Meadows-Jönsson for explaining the underlying reason to me
