AffixAllocator.suffix

Affix access functions offering references to the affixes of a block b previously allocated with this allocator. b may not be null. They are defined if and only if the corresponding affix is not void.

The qualifiers of the affix are not always the same as the qualifiers of the argument. This is because the affixes are not part of the data itself, but instead are just associated with the data and known to the allocator. The table below documents the type of preffix(b) and affix(b) depending on the type of b.

Result of prefix/suffix depending on argument (U is any unqualified type, Affix is Prefix or Suffix)
Argument TypeReturnComments
shared(U)[]ref shared AffixData is shared across threads and the affix follows suit.
immutable(U)[]ref shared AffixAlthough the data is immutable, the allocator "knows" the underlying memory is mutable, so immutable is elided for the affix which is independent from the data itself. However, the result is shared because immutable is implicitly shareable so multiple threads may access and manipulate the affix for the same data.
const(shared(U))[]ref shared AffixThe data is always shareable across threads. Even if the data is const, the affix is modifiable by the same reasoning as for immutable.
const(U)[]ref const AffixThe input may have originated from U[] or immutable(U)[], so it may be actually shared or not. Returning an unqualified affix may result in race conditions, whereas returning a shared affix may result in inadvertent sharing of mutable thread-local data across multiple threads. So the returned type is conservatively ref const.
U[]ref AffixUnqualified data has unqualified affixes.

Precondition: b !is null and b must have been allocated with this allocator.

  1. auto ref prefix(T[] b)
  2. auto ref suffix(T[] b)
    struct AffixAllocator(Allocator, Prefix, Suffix = void)
    version(StdDdoc)
    ref
    suffix
    (
    T
    )
    (
    T[] b
    )

Meta