Abstract We present the revolutionary complexity class O(whenever), designed for algorithms whose termination is not constrained by conventional metrics such as input size, runtime bounds, or even the known laws of physics. This framework liberates computer scientists from the tyrannical shackles of Big-O notation and provides a theoretical sanctuary for programs that "finish eventually, maybe." We demonstrate applications ranging from recursive Sudoku solvers that never quite commit to an answer, to distributed blockchain consensus protocols waiting indefinitely for Bob to respond.

1. Introduction

Traditional algorithmic analysis insists on predictable bounds: O(1), O(log n), O(n²), etc. This rigidity excludes algorithms that do not respect human notions of time. For example, a bubble sort implemented by a procrastinating undergraduate does not run in O(n²), but rather in O(whenever-the-student-submits). Similarly, certain operating systems have adopted boot-up sequences in O(whenever), defined by "the amount of coffee consumed by the user before giving up and restarting the machine."

2. Defining O(Whenever)

We formally define O(whenever) as:

For an algorithm A, A ∈ O(whenever) if its completion is not bounded by any computable function of input size, but rather by "circumstances," "mood," or "the whims of the scheduler."

This class subsumes NP, EXPTIME, and algorithms written in Python with excessive use of recursion.

3. Canonical Examples

3.1 Recursive Family Tree Traversal

def ancestry(person):
    if person is None:
        return []
    return ancestry(person.parent) + [person]

Runtime: O(whenever your genealogy app adds new relatives). Termination: never, due to distant cousins being born mid-computation.

3.2 Distributed Coffee Protocol (DCP)

Nodes communicate over Slack. Each message receives the reply: "Sorry, just saw this." Consensus eventually occurs in O(whenever-Bob-checks-his-notifications).

3.3 Quantum Random Number Generator (DIY Edition)

Algorithm: Wait for the cat to either die or not die. Runtime: O(whenever-quantum-decoherence).

3.4 Compiler Errors

Compilers already operate in O(whenever) when processing template metaprogramming in C++. Proof: developers stare at their screen indefinitely, waiting for the compiler to explain what went wrong.

4. Relationship to Existing Classes

  • O(whenever) ⊃ O(∞)
  • O(whenever) is orthogonal to O(n), but parallel to "technical debt."
  • P vs NP vs O(whenever) remains unresolved because no one bothered to check.

5. Applications

  • Scheduling meetings: Calendar invites processed in O(whenever-everyone-replies).
  • Smart home IoT devices: Lights turn off in O(whenever-the-firmware-update-finishes).
  • Academic publishing: Reviews are returned in O(whenever-the-referee-feels-like-it).

6. Conclusion

We have introduced O(whenever) as a formalization of reality's preferred runtime. Far from being a theoretical curiosity, it describes the dominant mode of modern computation. Future work includes O(never), already in use for printers.