[Pre-RFC] Option::for_some

I guess you mean a specialization of Apply for Option, otherwise I don't see how it helps.

Regarding the name for the operation, apply does not seem suitable to me (exactly because it is used for functions – see the notes about map above). However, naming is subjective… a poll might be useful to show the most acceptable name.

FWIW, in general I'd like if there were a way to distinguish at a glance whether a function (call) is pure or has side effects, via some sort of syntactic marker, not just by naming. Although I don't have a good suggestion off the top of my head how this should look exactly.

I understand, but I think that the concept of ownership, as implemented in Rust, and the existence of the mut keyword already cope with the issue very well. Some naming conventions already exists as well (e.g., the _mut suffix). On the other hand, I have doubts about any additional syntactic marker for functions with(out) side effects.

In the particular case of Option::map, it depends whether it may or may not accept FnMut. So the existing mechanisms apply here. Limiting it to Fn would force using (rather) pure functions, but it would be sometimes too restrictive, which would possibly imply another method (maybe map_mut?) accepting FnMut instead. Is it worth that all? I guess that most people would not be very happy.

Maybe it looks I've just made an argument against for_some :grin: Indeed, to some extent. The difference is that for_some produces nothing "useful" by its very signature, unlike map, so it makes sense to have it as the terminal operation that consumes the value with a side effect. It also hints that users might rather favour the approach where a chain of map-like transformations would use pure functions and the side effects would be carried out in the final for_some operation.

Alright, it is silent here. I think it's time to conclude. Here is the poll about the name, which I mentioned several times.

Which name(s) would you prefer after all?
  • for_some
  • if_some
  • consume
  • apply
  • Not listed here
  • None – I don't like this at all

0 voters

If there isn't suddenly strong opposition against the idea itself, I'll try to improve the proposal to include the concerns and alternatives mentioned in this thread and post an actual RFC.

Maybe also add consume_with as an option? Also, should the method return Option<()> or ()?

Alright, not very strong opposition, but quite strong. I hope that the votes against the proposal were considerate. In that case, I'm reluctant to make an actual RFC.

(I'm quite surprised with if_some being the most preferred option. Interesting.)

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.