Swift · Platform Notes

Platform Notes

3.0.0-rc.1 · 4c3e5023

§ What This Binding Does Not Expose

  • cursor and searchStream pull blocking, so a DenseIndexDeferredOn lacks them; contains is a test over count, so the deferred receiver offers count alone.
  • The constructors address no index yet, so no receiver offers them.

§ Design

  • A thin layer over the C ABI. Every name follows c/usearch/: a C verb usearch_dense_<verb> is a camel-cased <verb> here, such as saveBuffer, a type is its C name without usearch_ and _t, and enums mirror C enums, never strings.
  • The receiver chooses, the verb stays. The index runs a verb on the calling thread, on(executor) blocks on an executor, and deferred(executor) submits it, all with the same arguments.
  • Deferred calls use the language’s own idioms. status polls through usearch_outcome_status, wait() blocks through usearch_outcome_wait, and try await call.value runs that wait on a Dispatch thread, so an async caller suspends.
  • No life of its own. The binding starts no threads and keeps no queues; releasing a Deferred rides its deinit, which waits for the call first.
  • Arenas are lent and reused, never shared. Every output whose length scales with the call lands in an arena the caller passes; a view remembers which call wrote it and traps once a later one did.
  • Nothing costs anything until it is used. Submitting a call allocates nothing, and an arena allocates only when a call writes into it.
  • Every wrapper names its C symbol. Each wrapper’s documentation names the C function it calls or says it is binding-only, and a verb’s argument structure becomes its Dense*Config.