The Operation Concept

At first glance, one might expect Solidean to expose simple functions like
Mesh union(Mesh const&, Mesh const&) or Mesh difference(Mesh const&, Mesh const&).
Instead, the API is built around Operation objects that record a sequence of imports, Booleans, queries, and exports, which are then executed in one step by the Context.

This command buffer pattern is deliberate and has several advantages:

Deferred execution:
Nothing runs until Context::execute is called. This allows Solidean to optimize across the entire chain of operations rather than step by step.
Deterministic results & exactness:
Exact arithmetic is expensive. With a command buffer, intermediate results never need to be materialized unless explicitly requested. This keeps both memory and runtime predictable.
Safe ownership model:
Meshes, surfaces, and blobs are immutable. Operations work with operands inside a buffer. This prevents bugs like reusing a half-built mesh, and makes thread-safety straightforward.
Performance opportunities:
By seeing the full graph of inputs and outputs at once, Solidean can:
- fuse Booleans
- parallelize across sub-operations
- reuse shared intermediate constructions
- avoid redundant arithmetic conversions
Persistent chaining:
When you do want a mesh that survives beyond one operation (e.g. for iterated Booleans), you can materialize it via Operation::output and feed it back into a future operation.

Notes

This design may feel unusual compared to libraries with direct functions, but it is central to robustness and performance.
Most APIs (C, C++, Python) provide helper styles (e.g. Context::execute(lambda)) so the ergonomics are still concise.
If you only need a single Boolean, you can think of an Operation as "one function call with a bigger body". The overhead is negligible, and the benefits accumulate quickly once you chain multiple steps.
For a practical look, see the Examples or Guides. Every Boolean there is expressed via an Operation.