Re-name and Extend Run Conditions API

[CupOfTeaJay]

Objective

• My attempt at fulfilling Suggestion: Rename / Extend Condition Trait Methods. #13629.

Solution

Renames the and_then / or_else run condition methods to and / or, respectively.

Extends the run conditions API to include a suite of binary logical operators:

• and
• or
• nand
• nor
• xor
• xnor

Testing

• Did you test these changes? If so, how?

  • The test run_condition_combinators was extended to include the added run condition combinators. A double_counter system was added to test for combinators running on even count cycles.

• Are there any parts that need more testing?

  • I'm not too sure how I feel about the "counter" style of testing but I wanted to keep it consistent. If it's just a unit test I would prefer simply to just assert true == combinator output or false == combinator output .

• How can other people (reviewers) test your changes? Is there anything specific they need to know?

  • Nothing too specific. The added methods should be equivalent to the logical operators they are analogous to (&& , ||, ^, !).

• If relevant, what platforms did you test these changes on, and are there any important ones you can't test?

  • Should not be relevant, I'm using Windows.

Changelog

• What changed as a result of this PR?

  • The run conditions API.

• If applicable, organize changes under "Added", "Changed", or "Fixed" sub-headings

  • Changed:
    • and_then run condition combinator renamed to simply and
    • or_else run condition combinator renamed to simply or
  • Added:
    • nand run condition combinator.
    • nor run condition combinator.
    • xor run condition combinator.
    • xnor run condition combinator.

Migration Guide

• The and_then run condition method has been replaced with the and run condition method.
• The or_else run condition method has been replaced with the or run condition method.

[github-actions]

Welcome, new contributor!

Please make sure you've read our contributing guide and we look forward to reviewing your pull request shortly ✨

[alice-i-cecile]

Can you add and_then and or_else back, marking them as deprecated and calling the renamed methods in them? That will make migrations a bit easier for users and we can remove it right after it gets into a release.

I much prefer these names though, and the other logical combinations are useful enough.

[CupOfTeaJay]

Can you add and_then and or_else back, marking them as deprecated and calling the renamed methods in them? That will make migrations a bit easier for users and we can remove it right after it gets into a release.

I much prefer these names though, and the other logical combinations are useful enough.

Yes - will do

[JoJoJet]

I don't think we should rename these. The then keyword is intentionally used here to draw attention to the fact that these combinators short-circuit, which can already lead to surprising behavior when it causes systems to skip runs and retain old change ticks

[alice-i-cecile]

While that's an important fact about how these work, I don't think this naming convention was doing a good job conveying this information to users. 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 we should use clear, simple names, and explain this behavior better in documentation and other learning material.