You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
Context
The new
DelaunayTriangulationBuildergives us a staged, fluent construction path that better matches parse-don't-validate and removes the oldbuild::<()>()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
try_new*/try_with_*constructor family and decide what remains public, what is deprecated, and what should become lower-level/internal documentation.DelaunayTriangulationBuilderthe canonical public construction path across README examples, docs, doctests, integration tests, examples, and benchmarks unless a lower-level constructor is intentionally being demonstrated.global_topologynaming 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.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.build*terminals from 4 to 8+.Non-Goals