Add fallible closure to idioms #250
Conversation
tone was a bit condescending Co-authored-by: simonsan <[email protected]>
simonsan
added
C-addition
|
@jRimbault Do you still want to add anything or is it ready to review? |
|
I think it would be good to elaborate a bit more and give a better example, but yes I'm ready to review and change things if needed ? |
|
This was prompted by someone on reddit asking how to write the first two functions, to which I replied with the 3rd implementation. I think I've seen that idiom here and there in Rust code. |
| @@ -19,6 +19,7 @@ | |||
| - [Privacy For Extensibility](./idioms/priv-extend.md) | |||
| - [Easy doc initialization](./idioms/rustdoc-init.md) | |||
| - [Temporary mutability](./idioms/temporary-mutability.md) | |||
| - [Fallible closure](./idioms/fallible-closure.md) | |||
There was a problem hiding this comment.
We might find a better headline for the summary to let this idiom be found more easily.
There was a problem hiding this comment.
I agree, this often comes up when people want to avoid "arrow code" with let guards or "match hell", maybe something around that ?
|
The general question is also when you should do it and when not. I mean it's obviously pretty bad for error handling and I would consider it kind of an anti-pattern somehow in this regards, as also mentioned in the |
Co-authored-by: simonsan <[email protected]>
|
|
||
| ## Motivation | ||
|
|
||
| You may sometimes want to use the [`?`] operator inside an infallible function, |
There was a problem hiding this comment.
sometimes, here it would be good to give examples when that might be the case and when you would find this idiom in the wild.
| ## Motivation | ||
|
|
||
| You may sometimes want to use the [`?`] operator inside an infallible function, | ||
| in those cases a closure inside your function could be the simple solution. |
There was a problem hiding this comment.
why is this a good and simple solution in these cases, an explanation for it would be good
There was a problem hiding this comment.
Is this even an idiom? I thought it is just a syntax?
| This allows using the terser syntax permitted by the [`?`] operator inside an | ||
| infallible context. |
There was a problem hiding this comment.
Bit repetitive, it's good for this, because it's good like. maybe a bit more elaboration. maybe the text from my last comments would fit better in here then
|
|
||
| ## Disadvantages | ||
|
|
||
| This is hiding failure states from the consumer of the API. |
There was a problem hiding this comment.
why is that bad and when do you really want to avoid it? mentioning some cases would be good and probably also state, that if this is overused it could be considered an anti-pattern
|
I'll sleep on on your advice (it's 11pm in my timezone). I think I should first find some good examples (of good* and bad use cases). I've only had one legit use case. It's often came up when trying to help someone else though. IMO this should definitely not be in a function in a public API. It's really about syntax convenience when the author thinks they have a good default case. |
| fn file_stem(path: &Path) -> &str { | ||
| // this closure is fallible, so it can make use of `?` | ||
| // fn() -> Option<&str> | ||
| let inner = || Some(path.file_stem()?.to_str()?); |
There was a problem hiding this comment.
I believe this example is not making full use of ?, it could even have TryInto IIRC.
There was a problem hiding this comment.
It could be written :
let inner = || path.file_stem()?.to_str();but that wouldn't show much
There was a problem hiding this comment.
I do think that is better. I don't know why we need to have another layer for that.
simonsan
added
the
C-stale
|
Any updates on this? 🚀 |
This is a short idiom I think I've seen several times.
Using a fallible closure inside an infallible function to allow the use of the
?operator.