Cachex.get returning {:ok, nil} for missing values should be changed

[a3kov]

From the docs, currently Cachex returns {:ok, nil} for missing values, which not only breaks the pattern of :ok/:error tuples in Elixir, but makes it impossible to store valid nil values as it would be impossible to distinguish them. It should be fixed (in the next major version, as it would break existing code). The easiest fix would be to return :not_found or something like that.

[whitfin]

Reopening this to separately track the default get/3 changes to the rest of the thread.

Most of the context is in https://github.com/whitfin/cachex/issues/382#issuecomment-3417264420 and a handful of previous comments.

The gist is that at the very least we should allow for get/3 to operate similarly to Map.get/3 such that a user can store nil and easily differentiate by having a different default value.

Although this can be done technically in 4.x, it's easier to do so in 5.x as it's technically a breaking change within hooks.

[whitfin]

Hi @a3kov!

After thinking about this, I agree that we can improve things here. My plans here are:

• Add a third parameter for a default argument to get/4 (now get/3)
• This parameter is returned if the entry is missing, not nil
• This parameter defaults to nil if not provided
• Internally, fetch/4 will use a separate default to only fetch when values are truly missing

I think this should strike a good balance between backwards compatibility and addressing your (rightful) concerns.

If the user doesn't care to differentiate, then nil it is, if they do care then they can set a default value without me choosing and blacklisting one.

The only "negative" from this set of changes is that fetch/4 will now trigger only on missing, rather than nil, but as you say I think this is likely correct even if it is a breaking change.

Thank you for your input and help making things better!

[a3kov]

@whitfin Thank you for your work on this project. I think your solution is a reasonable compromise.