RFC: Moving fmt::Display from Predicates to a separate method

[XAMPPRocky]

With adding a way to show predicates with the item being evaluated keeping the current non-evaluated as the Display implementation is a bit confusing as two completely distinct ways of creating a humane readable string. I propose that the fmt::Display implementation be removed and be moved to a seperate method so that's easy to understand that when you want to display a human readable version of a predicate you call either of the methods.

Current

Evaluated

let predicate_fn = predicate::ne(5).not().and(predicate::ge(5));
let (result, output) = predicate_fn.stringify(&5);
println!("{}", output);

Non-evaluated

let predicate_fn = predicate::ne(5).not().and(predicate::ge(5));
println!("{}", predicate_fn);

Proposed

Evaluated

let predicate_fn = predicate::ne(5).not().and(predicate::ge(5));
let (result, output) = predicate_fn.stringify_with_item(&5);
println!("{}", output);

Non-evaluated

let predicate_fn = predicate::ne(5).not().and(predicate::ge(5));
let (result, output) = predicate_fn.stringify();
println!("{}", output);

[epage]

Before we answer this, we need to answer whether to have an "evaluated" version

Benefits of "evaluated"

• No confusion over a reused name showing up in an expression that means different things
  • Mitigated by breaking down the expression into smaller expressions with explanations (see A way to display *why* a predicate failed #60)

Benefits of no "evaluated" version

• Do not need to switch from Predicate<Item> to Predicate<Item: Debug>
• Overly long Display can hide information. An expression can be nice and short and the parameters / by-products can contain the long-form information (see A way to display *why* a predicate failed #60). We can work around it but its less of a whack-a-mole game without it.

In theory these points are also buried in the notes of #7. There might be more stuff there.

[epage]

I think with the current design, it is safe to stay with how things are.