You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'd like to propose a breaking change in the bit_array module:
Change the return type of the base64_encode, base64_url_encode, and base16_encode functions from String to Result(String, Nil).
They then return Error(Nil) if passed an unaligned bit array.
This came up as part of my work on unaligned bit arrays on JS. Currently on Erlang an exception is thrown, which I'm not sure is explicitly intended behaviour and is a bit awkward to deal with.
Alternatives to changing the return type:
Don't change the existing behaviour on Erlang, and throw an exception from the JS implementation on unaligned bit arrays.
Silently pad unaligned bit arrays with zero bits to reach a whole number of bytes, then encode that. This is probably a bit too magical/implicit though.
Thoughts?
The text was updated successfully, but these errors were encountered:
We definitely do not want to crash. Moving to using result would require making new functions with new names, deprecating the old ones, making new functions with the old names, and then deprecating the intermediate functions. Given the difficulty of this process I think it would be sensible to pad with zeros instead.
There is an outstanding ticket to do the same for bytes tree #320
I'd like to propose a breaking change in the
bit_array
module:base64_encode
,base64_url_encode
, andbase16_encode
functions fromString
toResult(String, Nil)
.Error(Nil)
if passed an unaligned bit array.This came up as part of my work on unaligned bit arrays on JS. Currently on Erlang an exception is thrown, which I'm not sure is explicitly intended behaviour and is a bit awkward to deal with.
Alternatives to changing the return type:
Thoughts?
The text was updated successfully, but these errors were encountered: