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
Even if it currently never errors, the API change in the PR made it possible to introduce an error without breaking API compatibility. So it was a matter of future-proofing the API.
(At least that is what I assume. I have not double-checked the details.)
Even if it currently never errors, the API change in the PR made it possible to introduce an error without breaking API compatibility. So it was a matter of future-proofing the API.
It’s not quite so simple. If you give the guarantee that the function never errors currently, even without changing the signature changing the behaviour of the function is still a way to break API compatibility. Suppose I .unwrap() the result of the function when I call it. This means either
I am relying on unstable behaviour that it won’t ever error, or
it is correct, and syntect actually gives the guarantee it won’t ever error, in which case the function signature is wrong.
In the docs, syntect doesn’t say anything about under what conditions the function is allowed to error; this means the documentation is underspecified, so this issue should still stay open.
In #432, the function was made fallible, but it can never return an error. Is this intentional? It was not mentioned in the PR.
The text was updated successfully, but these errors were encountered: