Since you can use
.into() to create a
Some, it'd be cool if
Some from prelude was deprecated, instead requiring the use of
.into() or an explicit
use std::option::Option::Some; to suppress the warning, with
.into() being the suggested approach.
Since you can use
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
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.
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(); x.is_some(); // further usage of x
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.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.