sqids-elixir icon indicating copy to clipboard operation
sqids-elixir copied to clipboard

Why no public `decode/2`?

Open vonagam opened this issue 11 months ago • 1 comments

Why decode!/2 does not have a public non-throwing counterpart?

vonagam avatar Mar 13 '24 19:03 vonagam

Hi! When adapting the Sqids spec to Elixir conventions, I found no “operational error” to return when decoding - for ex, decoding a string with characters unknown to the configured alphabet will just return an empty list instead.

However, decoding can still raise if you feed it a non-binary, or a binary that’s not UTF-8 encoded. These do not count as operational errors (in my intuition of Elixir convention) but rather as “you’re holding it wrong” cases, where non-bang versions of functions nevertheless raise.

I therefore considered: what if there is decode instead of decode!, returning only the unwrapped success, but then the spec or implementation change and errors need to be returned? - Breaking change.

So I chose decode!, even though it doesn’t raise on operational errors - because there are none - as it seemed less likely to break compatibility.

Reviewing my thinking, I speculate the purest implementation would have been a decode function that only returns {:ok, ids} …which could at a later version start returning {:error, _} if needed.

Would that be a breaking change? I say it would, or at least more so than an already raising function that starts raising on operational errors whereas it didn’t before.

I went into the weeds there. I hope my reasoning was clear, and I’m open to a new perspective on this, as I’ve debated myself in the past about bang-function semantics. I’ll leave this issue open for a while. Thanks for raising it! (No pun intended)

g-andrade avatar Mar 16 '24 02:03 g-andrade