`isZero()` & `isOne()` introduced to `NumericConstraintBase`.

[DiegoKrupitza]

Checking whether a given number is zero or one is now more pleasant to write and read. It is not longer needed to to use c -> c.equalTo(0) or c -> c.equalTo(1).

[making]

What are the use cases that require this constraint? Do you think the addition of this constraint will provide more value than the increased maintenance costs?

[DiegoKrupitza]

What are the use cases that require this constraint? Do you think the addition of this constraint will provide more value than the increased maintenance costs?

Although using integers as flags is not really good practice, it is sometimes needed due to language-agnostic interfaces. Lets say we have an enum:

public enum DeliveryType {
    TAKE_AWAY(0),
    DINE_IN(1),
    STAFF(2);

    private int type;

    DeliveryType (int type) {
        this.type = type;
    }

    // Method that gets the type variable.
}

Lets say we want to validate that the delivery type of a certain request is only TAKE_AWAY before mapping the value 0 to the correspondent enum value (for example of a REST Request as in here)

In this case it would make more sense to write c -> c.isZero() instead of the implizit and possible error prone c -> c.equalTo(0).

Furthermore, 0 and 1 are so special numbers in CS that it always gets special treatments (special constants in BigInteger, BigDecimal, special assertion functions in AssertJ, ... ).

[making]

Hmmm, it doesn't seem like a valid use case to me. Leave this PR open until further requests come in.