Skip to content

Normalize public APIs that take Path #78

@mxpv

Description

@mxpv

Follow-up to #75 (comment)

Today every public method that takes a path uses impl Intosdf::Path — for example Stage::define_prim, Stage::field, Stage::value_at, StagePopulationMask::add_path. Combined with the existing impls in src/sdf/path.rs:

impl From<&str>   for Path { fn from(s: &str)    -> Self { Path { path: s.to_string() } } }
impl From<String> for Path { fn from(value: String) -> Self { Path { path: value } } }

This means any string at all is accepted as a valid sdf::Path with zero validation. Invalid input ("World", "/foo bar", "//double", "/Prim.attr.sub") silently produces a Path that downstream code then has to defensively re-validate or that produces wrong results.

This also makes a fallible impl TryFrom<&str> for Path impossible to add cleanly because the infallible From is already in place.

  1. Public APIs accept impl TryInto<sdf::Path, Error = ...> instead of impl Into<sdf::Path>. Strings get validated on conversio.
  2. Internal APIs that already operate on validated paths take &Path / Path directly — no conversion, no revalidation. Where construction is provably safe (e.g. building a child from a validated parent + identifier), Path::from_str_unchecked stays the fast path.
  3. Drop the existing impl From<&str> for Path and impl From<String> for Path so the "unchecked" door isn't left open by accident.
let binding = mesh
    .create_relationship("material:binding")?
    .add_target(sdf::Path::new("/World/Material")?)?;
...
let binding = mesh
    .create_relationship("material:binding")?
    .add_target("/World/Material")?;

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions