Isaac Whitfield

Just following up to this with my latest thoughts here: I am intending on (time permitting) a v5.0 which will address most of these issues based on the [naming conventions](https://hexdocs.pm/elixir/main/naming-conventions.html)....

I plan on removing the `!` versions wherever possible, based on this snippet from the Elixir conventions: > Errors that come from invalid argument types, or similar, must always raise...

@a3kov how would you suggest changing that without causing the same issue with some other value?

Right -- but that then just means it's not possible to store ':not_found'. There will always be some clash, but 'nil' is pretty traditionally used to represent "no value". The...

Ah, @a3kov, I see what you're saying. Given the scope of the changes that people want (i.e. no more return tuples), how would you represent a missing value here? It...

> As far as I see there's no reason to do that. Absence of cached value is not an exceptional situation - quite the opposite. For what it's worth I...

Hi everyone! Just a note to say that work has begun on the directions specified in this thread in a separate branch; once things are functional, it'll be merged into...

After starting a lot of the work for the main changes in https://github.com/whitfin/cachex/pull/426, it's clear that there are already spaces to improve before a 5.x is out. For the most...

As a note, the new forms are quite verbose. It would be nice that places supporting this had some property to trim things down (context https://github.com/whitfin/cachex/issues/382#issuecomment-3468570692). We can group all...

This should also include revisiting how the `!` of these functions interact; currently they're unpacked but I'm not entirely sure if that's what we want...