TypedBlobs and DataSlots

Why results are output-only, flexible, and immutable, and how DataSlots organize them.

One of the central abstractions in Solidean is the TypedBlob, which represents the output data of an operation.
Unlike meshes or operations, blobs are never inputs. No API call consumes a TypedBlob in a semantic way.

This shapes the design:

  • Output-only:
    Blobs are produced by operations and then inspected or exported by user code. They never participate in further operations.
  • Flexible typing:
    Because results may vary widely (Triangles, IndexedPolygons, HalfedgeExplicit, …), Solidean does not expose a rigid type hierarchy. Instead, each blob carries a type tag (its BlobType).
  • Slot-based access:
    Within a blob, each dataset is stored in a contiguous array identified by a DataSlot. This gives the performance of raw spans of bytes, while still preserving semantic meaning.
  • Conditional population:
    Operations may populate different subsets of slots, e.g. depending on the chosen ExportFormat and ExportOption.
    For example, exporting indexed triangles with positions and IDs will yield TrianglesIndexed, PositionsF32, and PrimitiveIDs slots.

In short:
A TypedBlob is essentially a collection of span<byte> segments, each tagged with a DataSlot to define its semantics, and gated by a global BlobType tag for overall interpretation.

Why this design?

  • Performance:
    Contiguous arrays with no indirection are trivial to work with in low-level languages (such as C++) and map efficiently to external systems.

  • Flexibility:
    Hundreds of valid output combinations exist (different formats, attributes, manifoldness guarantees). Slots let Solidean express these without combinatorial explosion of types.

  • Safety:
    Blobs are immutable. Once created, they cannot be modified, which makes them trivial to share across threads without synchronization.

Notes

  • The “shared-immutable” pattern is an overarching theme in Solidean. Blobs follow the same design principle as meshes: they are created once, never mutated, and safe to use concurrently.
  • While blobs themselves are immutable, you can always copy out their arrays into your own editable data structures.
  • The separation of semantic slots from raw storage makes it easy to extend Solidean with new slots in future releases, without breaking old code.