tess::IntentPayloadView Struct Reference

#include <tess/ops/queued.h>

Public Member Functions
template<typename T>
auto	holds () const noexcept -> bool
auto	bound () const noexcept -> bool
template<typename T>
auto	as () const noexcept -> std::span< const T >

Static Public Member Functions
template<typename T, std::size_t Extent>
static auto	from (std::span< T, Extent > values) noexcept -> IntentPayloadView

Public Attributes
const void *	data = nullptr
std::size_t	count = 0
std::size_t	item_size = 0
std::uintptr_t	type_identity = 0

Detailed Description

Type-checked, non-owning view of one homogeneous intent batch.

Its type token is unique only within one binary image. Do not compare or consume payload identity across a shared-library boundary; the result is unspecified and toolchain-dependent.

Member Function Documentation

as()

template<typename T>

auto tess::IntentPayloadView::as ( ) const -> std::span< const T >

inlinenodiscardnoexcept

Returns the batch as std::span<const T>; holds<T>() is a precondition.

Once the precondition holds, an empty result means the batch is empty and nothing else. Before, it also meant "this view carries some other type" and "this view carries nothing at all", so a caller that asked for the wrong type processed zero items every operation batch with no signal — the failure the assertion now names. Use holds<T>() where the type is genuinely in question, and bound() to skip payloadless operations.

The typed OperationBatch entry points pair each OperationKind with the payload type it names, so a consumer dispatching on kind over operations from those entry points has the type fixed for it and a mismatch is a caller bug. Nothing enforces that pairing on a hand-built QueuedOperation or PlannedOperation::create, whose kind and payload are independent fields.

With assertions compiled out the empty span remains the fallback, so a release build degrades to the old silent behaviour rather than reading the batch as the wrong type — which also means the "empty means empty" reading above is only true there when the caller has checked holds<T>() itself.

bound()

auto tess::IntentPayloadView::bound ( ) const -> bool

inlinenodiscardnoexcept

True when any batch was attached, of any type.

Distinguishes an operation that carries no payload from one whose batch is empty. It says nothing about whether the viewed storage is still alive: this is a non-owning view, and a dangling data is indistinguishable from a live one here.

holds()

template<typename T>

auto tess::IntentPayloadView::holds ( ) const -> bool

inlinenodiscardnoexcept

True when this view carries a batch of T.

The gate to check before as<T>(), and the only way to tell a batch this view does not carry from one it carries and that happens to be empty. Identity is a per-type token guaranteed unique within one binary image and nothing more, so the answer for a view produced in another image is unspecified and toolchain-dependent: do not compare payloads across a shared-library boundary (docs/integration-policy.md states the same caveat for the token itself).

---

The documentation for this struct was generated from the following file:

• include/tess/ops/queued.h