Skip to content

Polish and finalize Delaunay construction builder API for v1.0.0 #497

Description

@acgetchell

Context

The new DelaunayTriangulationBuilder gives us a staged, fluent construction path that better matches parse-don't-validate and removes the old build::<()>() turbofish for the common case.

This issue is intentionally scoped to v1.0.0. We should let the v0.8.x and v0.9.x APIs cook under real usage first, especially from examples, benchmarks, paper workflows, and downstream consumers such as causal-triangulations, before finalizing the public construction surface.

Scope

Polish and finalize the Delaunay construction builder API before 1.0.0, with an emphasis on correctness, orthogonality, fluent ergonomics, and minimizing redundant public construction paths.

Acceptance Criteria

  • Collect usage experience from v0.8.x and v0.9.x before making breaking API decisions.
  • Audit the legacy try_new* / try_with_* constructor family and decide what remains public, what is deprecated, and what should become lower-level/internal documentation.
  • Make DelaunayTriangulationBuilder the canonical public construction path across README examples, docs, doctests, integration tests, examples, and benchmarks unless a lower-level constructor is intentionally being demonstrated.
  • Revisit global_topology naming and semantics. Decide whether to keep the current name, rename it to something metadata/expectation-flavored, or strengthen documentation enough to avoid confusing it with toroidal construction.
  • Add the topology metadata setter to the builder module decision table with the explicit caveat that it is metadata/validation expectation only.
  • Re-evaluate simplex_data_type::<W>() naming after real usage. Keep it if it remains clear, or rename before 1.0.0 if a better type-state name emerges.
  • Keep the builder terminal surface from expanding combinatorially. If a new axis appears, prefer a design that does not grow build* terminals from 4 to 8+.
  • Sweep cfg-gating and Clippy hygiene around builder-related optional features.

Non-Goals

  • Do not block v0.8.0, v0.8.1, or v0.9.0 on this polish.
  • Do not remove legacy constructors until there is enough real usage evidence to know which ones still carry orthogonal value.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions