Deprecate `ok_or` method #51292
Deprecate `ok_or` method #51292
Comments
There are good use cases for |
In my expirience you almost never want to return just a const. All errors in common libraries follow this pattern
Creating |
Closing: this discussion should be moved to internals as a precursor to an RFC; we aren't likely to change anything with a stable method without an RFC. |
There is plenty of issues when people unintendely use the eager version of mapping result method just because it saves some typing. It results in confusion among the community as well as performance issues in compiler.
Rust is going into the new epoch, so it's a good time to resolve this mistake.
The proposal is:
ok_or
method onResult
type. We already have a lint in clippy that suggest to replace it withok_or_else
if any computations are done there. It's a good signal that it shall be done. On the other hand,or_or_else
with constant value lambda would be always inlined and thus have same performance as before.ok_or
. Replace it withok_or_else
implementation.ok_or_else
could be a deprecated alias forok_or
with lambda as parameter.The phase 2 looks a bit confusing, but as said it would save some typing. Or it could be done in one big step. It would break the existing code, however it's an ok breakage as it's easy to fix it automatically (via just
grep
replace). We are already going to break some code withdyn Trait
so it's not new for us.This probably requires an RFC, I didn't do one yet, but I think we may collect some feedback here. Do you feel that compiler is smart enough to inline constant functions and we can remove some confusion and possible bottlenecks? Do you accept to type a bit more (
else(||
part) or it's too high cost (among others like deprecation and code breakage)?The text was updated successfully, but these errors were encountered: