Struct BoundCliSpec 

pub struct BoundCliSpec<R> { /* private fields */ }

A built registry with exactly one handler per action.

Implementations

impl<R> BoundCliSpec<R>

pub fn resolve_from<I, S>(&self, args: I) -> Result<BoundOutcome<R>, CliError>

where I: IntoIterator<Item = S>, S: Into<OsString>,

Resolve argv against this registry, binding the run branch to its handler as it goes.

The handler is attached here, where bind_actions has already proved one exists for every action, which is what makes BoundInvocation::run infallible. Resolving through the registry that owns the handlers also removes the possibility of dispatching an invocation from a different registry: there is no longer a step that takes one.

pub fn call_every_combination(&self) -> Vec<(String, R)>

Call every declared combination’s handler with strict argument reads, returning each combination id with what its handler produced.

This runs your handlers. Every one of them, on synthetic argv, in whatever order the registry declares them. Use it only where a handler is a pure projection of argv into a command value. Where the handler is the command, this will do whatever the command does — bind a port and never return, open a terminal, write files, or uninstall something. The name of this method is not a promise that it is safe to call; the shape of your handlers is.

Where it does fit, it is the other half of ResolvedInvocation::required being infallible. A handler that reads an argument id its combination does not declare gets a failed read in production — silent, and exactly the class of typo no compiler catches. Here it panics naming the combination and the id, driven by the same synthetic invocations BuiltCliSpec::synthetic_invocations generates for help and docs. Production code carries no branch for a case it cannot reach, and the case is still caught before it ships.

If your handlers are not callable here, that is worth reading as a design signal rather than a limitation of this method: separating “parse argv into a typed command” from “carry the command out” makes the check available and is the better shape independently.

The results are returned rather than discarded because a handler that returns a Result has a second thing worth checking — that every combination actually builds — and a caller that had to write its own loop for that would be back to hand-rolling the half this replaces. Ignore the return when the handler’s output says nothing useful.