Add `if x in option` syntax sugar

[CAD97]

There’s a problem with human ambiguity though; if x in container is handled as if container.contains(x).

For this reason I’m loosely in favor of not adding this, but could be convinced if someone could provide a benefit of not just writing it as if let Some(x) = container, which would probably be some application beyond just Option which has Some/None in the prelude and isn’t used as if let Option::Some(x) = container.

[soc]

Currently we use if let Some(x) = option, which works, but is a bit verbose.

What about if option.contains(x)?

(I suggested addressing this API gap some days ago.)

[Nemo157]

But isn’t that how for x in iter works?

That’s actually an interesting point. I wonder if Rust ever experimented with for let x in iter pre-1.0, that seems more consistent with most of the languages I can think of.

Pre-post edit: Browsing the rosetta code page on foreach it seems I just managed to come from the smaller subset of languages that require an explicit declaration in their foreach loops, most of them are consistent with Rust in that the foreach loop implicitly declares new bindings for the loop variable.

[withoutboats]

I agree that the most compelling reason not to do this I’ve seen in this thread is that other languages have x in y as a boolean operation.

[160R]

Creating a new binding without a match or let is surprising.

But it’s not surprising to create a new binding with in.

I would definitely find an if-in syntax like this confusing when most languages (that I know of) use this as some sort of operator-in .

That’s true, but I might argue that to those who don’t know other languages and don’t familiar with pattern matching, if x in option might be simpler than actual version. Also, it depends on context where you see this syntax, e.g. on the following examples it should be more straightforward:

    if next_value in iter.next() { ... }

    if value in container[key] { ... }

    if value in opt_value { ... }

Using Try like this necessarily entails ignoring the error case, for an Option that’s ok, but if bar was a Result there’s nothing locally here telling you that you’re ignoring the error

That good point. So, this might be restricted only to Option<T> or something like std::ops::Container<T>

[scottmcm]

The same idea already applied in for x in iter syntax, which effectively replaces while let Some(x) = iter.next() .

That’s an interesting observation, but it’s incomplete in a way that I think obscures a large part of the value: the IntoIterator::into_iter call and resulting temporary.

So what if there were an IntoOption trait? Would that be useful? I could imagine something like

if x in &some_mutex { x.foo() }

instead of

if let Ok(x) = some_mutex.lock() { x.foo() }

But I can’t decide if lock() or try_lock() is right there, and I don’t know if this is even ever a good idea.

(Especially if a option is Some(x) expression were to happen, like as been discussed before, which IMHO is short enough, while being more general and composing better, though I’m still uncertain about the binding scope questions.)

[newpavlov]

I think that proposed behaviour of if x in smth { .. } originates from false idea of coherency with for item in items { .. }. As I see it, the main reasons why we have this form of for syntactic sugar is because it is “nice to read” as “for every item in items do stuff”. So if we’ll look at if x in smth { .. } from this perspective we can see that coherent behaviour will be the Pythonic one, i.e. sugar for if smth.into_iter().any(|v| x == v) { .. }, because, well, we read it as “if x in smth do stuff”, and any other behaviour will be a constant source of cognitive dissonance.

[eugene2k]

I’d rather have if x in y mean the same thing it does in python. People learning rust after python are sure to appreciate that, I think, and with python being one of the most beginner-friendly languages, there will be a lot of people familiar with it.

[madmalik]

Counterproposal:

Allowing else on for constructs would have the desired effect for usage with Option and would be useful in other situations, since empty collections is a common corner case. I don’t know if this was discussed in the past, but i assume so since this is a fairly obvious idea…

[Emerentius]

for else where the else-case is executed when the loop is never entered has been discussed before. Iirc the main reason we can’t use the the else keyword for that is because Python has poisoned the else syntax with a very different, unfitting meaning. It’s entered if the loop was not broken out of.

[160R]

But I can’t decide if lock() or try_lock() is right there, and I don’t know if this is even ever a good idea.

If there were an IntoOption or similar trait, it will be better to implement it for LockResult only, which will be more explicit:

if x in some_mutex.try_lock() { x.foo() }

if x in some_mutex.lock() 

Especially if a option is Some(x) expression were to happen, like as been discussed before, which IMHO is short enough, while being more general and composing better, though I’m still uncertain about the binding scope questions.

I think that if option is Some(x) { ... } dont differs too much from if let Some(x) = option.
What will be wrong with x in option syntax to be also evaluated to bool?

[160R]

the main reasons why we have this form of for syntactic sugar is because it is “nice to read” as “for every item in items do stuff”

What’s more important is that this syntax reduces cognitive load when dealing with such code. It strips information that’s obvious. Why should we read everytime that we deal with Option if we know that probably in 99% of the times?

if we’ll look at if x in smth { .. } from this perspective we can see that coherent behaviour will be the Pythonic one, i.e. sugar for if smth.into_iter().any(|v| x == v) { .. } , because, well, we read it as “if x in smth do stuff”, and any other behaviour will be a constant source of cognitive dissonance.

But what’s wrong with such interpretation? It’s right and it even don’t differs too much with Python version (in both versions we do checking if x is present in container, in both this might be true, and in both versions then we can “do stuff” on that x. Only one difference is where x introduced)

[160R]

Counterproposal:

Allowing else on for constructs would have the desired effect for usage with Option and would be useful in other situations, since empty collections is a common corner case. I don’t know if this was discussed in the past, but i assume so since this is a fairly obvious idea…

But for value in option is confusing and misleading and implementing else will not help with that.
Even when it reads fluently, when I see for I always expect loop to be next, and not sole value presence check.

What’s worse is that such syntax is side-effect of implementing IntoIter for Option (which probably was primarily to be able to use Option in combinators like flat_map).

I hope in future it will be linted and if value in option will be proposed instead

[CAD97]

I find that it can be useful to think about Option as a single-or-no-element iterator in other contexts as well. I think even outside of the utility of using it in contexts that take IntoIterator, it definitely should be IntoIterator.

for element in option { do stuff } is still correct, it’s just that the loop only runs zero or one times, rather than zero or more times. It’s calling regex ? a repetition ({0,1}) in addition to + ({1,}) and * ({0,}).

If a syntactical form existed for IntoOption to specifically cater to the zero-or-one case, then I’d support a clippy lint to prefer that when both IntoIterator and IntoOption are available, but not a rustc lint. I think they already get optimized to the same end code anyway, it’s just a matter of rustc being able to assume the block is run a maximum of one time for type and borrow checking.

The problem I see with if value in option is that I expect that to mean if option == Some(value) (or if option.contains(value), not if let Some(value) = option. for always creates a name, if never does, let does irrefutable pattern matching assignment, and if let does conditional scoped refutable pattern matching assignment.

At a glance, what do you expect the following code to do?

let option = Some(10);
let value = 5;

if value in option {
    println!("if  : value = {}", value);
} else {
    println!("else: value = {}", value);
}

for value in option {
    println!("for : value = {}", value);
}

My intuition says else: value = 5/for : value = 10, because so far I’ve been trained that if cannot introduce new bindings. That’s also why I’m weakly against if option is Some(value) without getting some other benefit from it (which I think exists but I cannot recall at the moment).

[H2CO3]

code should be easier to read, write, and maintain

I don’t think, for one, that if let Some(x) is such a burden or in fact that it’s hard to read or maintain at all. I don’t see the point in adding syntactic sugar for it at all. It’s neither long or verbose, nor does it need much repetition (it does exactly one thing).

I do find, however, that if x in something is pretty confusing because many languages (and programmers) interpret it as something.contains(x).

[160R]

Thinking about your reply I’ve found that IntoIterator, value in container and expression is pattern things might be conceptually arranged wery well and it will be not so hard to adapt to them.
Consider the following set of features:

1. expression is pattern evaluates to bool and there no scoping issues
2. val in container also evaluates to bool and there also no scoping issues
3. IntoIterator provides in syntax and there no additional types like IntoOption
4. for x in iterator is deprecated in favor of while x in iterator
5. #[iter_once] used on Option<T> to promote using if instead of while and if is version
6. #[iter_never] used on Result<T, E> to prohibit error case ignoring

[160R]

I don’t think, for one, that if let Some(x) is such a burden or in fact that it’s hard to read or maintain at all. I don’t see the point in adding syntactic sugar for it at all. It’s neither long or verbose, nor does it need much repetition (it does exactly one thing).

It uses too many unnecessary symbols to express that, and syntax is not very welcome.
We can live with that - surely, but I feel that feature which is so commonly used (not only in Rust) should have better syntax

I do find, however, that if x in something is pretty confusing because many languages (and programmers) interpret it as something.contains(x) .

I have strong feeling that if x in something syntax like in other languages is one of those things which are inconsistent and should not be copied blindly to please everyone (like classes, inheritance, manual memory management, switch statements, etc.).
If there will be benefits of feature I don’t see behavior of mainstream languages to be a significant problem when implementing it. Rust is different language and it can behave differently, it can implement things differently and even it positiones itself as language which does that.

[CAD97]

and there are no scoping issues

That’s terribly unspecific…

let iter: &[u32] = &[0, 5, 10][..];
let x = 5;
if x in iter {
    // does this work? What's the scoping?
    // there's "no scoping issues"
}

There’s nothing that evaluates to bool that also introduces a binding currently in Rust. And having a side effect is definitely a foot gun.

[160R]

Scoping is exact the same as with:

let iter: &[u32] = &[0, 5, 10][..];
let x = 5;
for x in iter {
    // does this work? What's the scoping?
    // there's "no scoping issues"
}

x in iter part certainly says that new binding is introduced. Personally I’ve never had any problem with code like that.

There’s nothing that evaluates to bool that also introduces a binding currently in Rust. And having a side effect is definitely a foot gun.

I saw some proposals to evaluate x is Some(y) expressions to bool. All problems with scoping and visibility was around || operator.
All that I’ve written in previous comment depend on that

[CAD97]

x in iter part certainly says that new binding is introduced

That’s where we differ I guess. For me, for is the construct that does the introducing of the binding for me. I read a for, new binding. I read an if, it’s an expression, and thus doesn’t introduce a new binding.

At least currently, $ident in $expr is not an expression. The construct is for ... in ... { ... }, and in is not its own thing; for is the actual driving force in this situation.

Let’s be explicit: what is your suggested desugar for each of: (and consequently, which pass typeck)

Given a pre-existing variable it, statement context

x in it;

x in it;
x in it;

iter::once(x in it);

let y = x in it;

let y = x in it;
let z = x in it;

if x in it {
    do_something(x);
}

let x = if x in it {
    do_something(x)
} else {
    default()
};

if x in it {
    do_something(x);
}
if x in it {
    do_something(x);
}

if x in iter::once(x in it) {
    do_something(x);
}

let y = iter::once(x in it);
if x in y {
    do_something(x);
}

(Repeat every case of if ... in ... { with for and while instead of if)

Illegal construct is a viable answer. Please make sure that you provide a reasoning for what is and isn’t legal, though, and it cannot depend on types – that’s typeck, which is after the parse.

EDIT 1: since you seem to be implying that x in iter would be an expression, throw in some other combinations like logical operators as well, x1 in it1 && x2 in it2, x in it1 || x in it2, in the above contexts as well.

EDIT 2: if you can provide a solid consistent rule for how in is desugared that can be applied to all of these cases, you don’t have to enumerate them; I/we can pick out the problematic ones then.