Deprecate Some from prelude

Since you can use .into() to create a Some, it'd be cool if Some from prelude was deprecated, instead requiring the use of Option::Some, .into() or an explicit use std::option::Option::Some; to suppress the warning, with .into() being the suggested approach.

Some is IMO way nicer to read than into(). I wasn't actually really aware of the fact that there's a impl From<T> for Option<T>. Also, having Some in the prelude is necessary for avoiding Option::Some in pattern matching. In particular if let Some(x) = ... or while let Some(y) = ... is super common (so much so that in the case of ... being a .next() call on an iterator, there's special syntax for it, the for loop). Making that pattern so much more verbose seems IMO problematic.

Also note that into has problems with type inference that make it less useful than an explicit Some. E. g. you can write let x = Some(y) today, try doing this with into.

Finally, the decision to depricate Some in the prelude is something that needs way better arguments than a decision to not include Some into the prelude in the first place would have needed. Rust doesn't like introducing "breaking" changes for no good reason. In particular you haven't actually provided any reason for depreciating it yet (other than an “it would be cool” with no explanation as to why). You just argued what could be used instead, so, well, feel free to use alternatives if you want, but what is the actual advantage of depreciating Some in the prelude over just keeping it as it currently stands?


this should be in the prelude: std::iter::from_fn - Rust. (also Option has into_iter.)

...doesn't that work fine if x is used?

warnings aren't breaking changes, but see also Option shorthand pre-pre-rfc. tl;dr: there isn't enough momentum for Into, so it's unlikely we'll ever get syntax for Into... so the solution is to encourage ppl to use Into and then there'll be momentum for Into and then there'll be syntax for Into.

That's why I used quotes around the word "breaking". Warnings do break the warning-free-ness of code, so they can break the CI in Rust project, in turn somewhat "forcing" or at least encouraging lots of people to take the effort to make changes to their Rust code.

1 Like

only if that usage helps the compiler to find out what type is needed. Something like e. g.

let y = 1;
let x = y.into();
// further usage of x

doesn't currently work.


I don't see any benefit of doing so. Having Some doesn't cause any problems, and there aren't any other Some implementations waiting to be used instead. It's not part of any niche or deprecated functionality.

And it would cause catastrophic amount of churn. Pretty much every Rust crate uses it. Huge waste of everyone's time.


As a library team member, I'll just nip this one in the bud: it ain't happening.