Add non-short-circuiting run conditions and re-rename short-circuiting run conditions to be explicit about bevy HOT 9 OPEN

If we end up introducing non-short-circuiting variants, I think those should be the ones to get the longer name, as they're generally going to be dispreferred. Shortcircuiting is a real footgun, but it's rarely stumbled on.

After seeing how run conditions are used in practice, most conditions don't use change detection or event readers, which are the main worry.

We could add docs to the built in combinators that do as well to help warn users?

from bevy.

I think or_else and and_then are fine. It corresponds to methods on Option with similar behavior so many users will already know how it works, plus it's a non-breaking change to go back to those names

from bevy.

@JoJoJet, spinning this out into an issue. We should resolve this one way or another for 0.15. I definitely agree with your concern, I just don't think that the names are a good way to communicate this :)

from bevy.

As evidenced by the fact that users regularly asked "why is it called and_then", and answerers didn't point to "oh that's because it's short-circuiting".

IMO that's the name having its intended effect. The problem is people not answering with the actual reason. The name is supposed to make you go 'huh that's weird, I wonder why it's named like that' so you go looking. If there's a simple name then it's really not clear that there's a huge asterisk when it comes to the system's heavior

from bevy.

@JoJoJet
@alice-i-cecile

I would argue that most are using the combinators to just achieve some logical output, that is without taking advantage of the short-circuiting behavior - but maybe there is a better solution here:

Maybe refactor interface to be:

This has the following advantages:

• The name of the combinator used explicitly indicates whether or not it is short-circuiting by virtue of the _short suffix. This is much less ambiguous than _then or _else, enough to where I imagine if anybody is curious about what _short means other users who know will probably give the "because it's short-circuiting" answer.

• No suffixes are added for non short-circuiting combinators. This should be straightforward for users who just want a simple logical output, and the intent (to my understanding) of the original pull request.

Disadvantages:

• This would probably bloat the interface some more.

from bevy.

For context, the short circuiting is actually mostly a performance optimization, rather than a deliberate behavioral choice.

from bevy.

For context, the short circuiting is actually mostly a performance optimization, rather than a deliberate behavioral choice.

Right - that's exactly what I thought. I imagine @JoJoJet 's concern is that perhaps there are users who deliberately want to take advantage of the behavior, and have it not be ambiguous.

from bevy.

If we end up introducing non-short-circuiting variants, I think those should be the ones to get the longer name, as they're generally going to be dispreferred

I really don't agree with this. Non short-circuiting should get the shorter name since it's more reliable and generally has fewer considerations. In general, I believe any option that is faster but requires you to know what you're doing should get a longer, more descriptive name

from bevy.

Hmm, fair. Let me bikeshed some names. If we add non-shortcircuiting nicely named variants I think I'm on board.

Candidates:

• and_short: mysterious, but short to read
• and_short_circuit: very clear, rather a mouthful
• and_then: not obvious, same can't be used for or
• and_&&: is this even legal? It's definitely unidiomatic
• and_if: short, legible, weird enough to pick up that something weird is going on

I think and_if is my favorite, followed by and_short_circuit. and_short is fine, but meh. Everything else is pretty bad.

from bevy.