Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Why no public decode/2? #25

Open
vonagam opened this issue Mar 13, 2024 · 1 comment
Open

Why no public decode/2? #25

vonagam opened this issue Mar 13, 2024 · 1 comment
Assignees

Comments

@vonagam
Copy link

vonagam commented Mar 13, 2024

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

@g-andrade
Copy link
Collaborator

g-andrade commented Mar 16, 2024

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 g-andrade pinned this issue Mar 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants