Conditions and bool

Every condition in Nitpick is strictly of type bool. This applies uniformly to if, else if, the is ternary, while, till, and when.

if (x < 5i32) { ... };          // OK: `<` yields bool
int32:y = is (ready) : 1i32 : 0i32;   // OK: `ready` is bool

There is no truthiness

Unlike C, a non-zero integer is not true, a null pointer is not false, and a bare Result is not a condition. Each of these is a type error at the condition position:

if (count) { ... };             // ERROR: condition must be bool, found int32

Write the comparison you actually mean:

if (count != 0i32) { ... };     // OK

This is a deliberate design choice: it removes a whole class of silent bugs where an assignment or a wrong type slips into a condition. The ARIA-IF-002 diagnostic exists for exactly the most common such slip — writing = instead of ==. See Diagnostics.

Result<bool> must be unwrapped

A function that yields bool actually returns Result<bool>, because any Nitpick function can fail. A Result<bool> is not a bool, so it is not a condition on its own:

if (is_ready()) { ... };        // ERROR: condition is Result<bool>, not bool

Unwrap it with raw to get the underlying bool:

if (raw is_ready()) { ... };    // OK

raw propagates the error path; if is_ready() produced an error, the raw unwrap fails through the function's failure path rather than silently treating the error as false. Use raw only when you have already established (or are willing to propagate) that the call succeeds.

Boolean operators

Conditions compose with the short-circuiting && and || operators and the ! negation, all of which take and yield bool:

if (raw is_ready() && count > 0i32) { ... };
if (!done || retries < 3i32) { ... };

The same operators work inside an is condition:

int32:state = is (raw is_ready() && count > 0i32) : 1i32 : 0i32;