Is it possible to statically check a value_parser type against an argument value type?

[BergmannAtmet]

As a trivial example:

use clap::{Command, Arg, Parser, builder::TypedValueParser};
use std::ffi::OsStr;

#[derive(Clone)]
struct ZeroF64;

impl TypedValueParser for ZeroF64 {
    type Value = f64;

    fn parse_ref(&self, _: &Command, _: Option<&Arg>, _: &OsStr) -> Result<Self::Value, clap::Error>
    {
        Ok(0.0)
    }
}

#[derive(Parser, Debug)]
struct Cli {
    #[clap(long, value_parser=ZeroF64)]
    n: usize,
}

fn main() {
    dbg!{Cli::parse()};
}

A compile-time error for the mismatch between f64 and usize would be desirable.

[RenSolvyn]

Short answer: no, not currently, and this is a known open limitation rather than something you are doing wrong.

Why it is not caught at compile time

In the derive API, value_parser = ZeroF64 and the field type usize are wired together at runtime, not through the type system. clap stores the parsed value as a type-erased Any and checks the TypeId when you access it. So the mismatch between TypedValueParser::Value = f64 and the field type usize is only discovered when the value is fetched, and it surfaces as a downcast panic like:

Mismatch between definition and access of `n`.
Could not downcast to usize, need to downcast to f64

There is a long-standing issue tracking exactly what you are asking for: #4830 "better compile time validation of value_parser types". The maintainer response there acknowledges the failure happens in verify_arg_t at runtime and that this "should be detectable at compile time". It is still open, so worth a thumbs up if you want to signal demand.

The underlying reason is that #[derive(Parser)] generates builder calls, and the builder's value_parser accepts anything implementing IntoResettable<ValueParser>. Once the parser is boxed into a ValueParser, its Value associated type is erased and there is nothing left for the compiler to compare against your field type.

The workaround: .map()

The practical fix is to make the parser actually produce the field type, using TypedValueParser::map. In your example:

use clap::builder::TypedValueParser as _;

#[derive(Parser, Debug)]
struct Cli {
    #[clap(long, value_parser = ZeroF64.map(|v| v as usize))]
    n: usize,
}

Now the type flows through: ZeroF64 yields f64, .map() converts to usize, and the field is usize. If you change the field type without updating the closure, you get a compile error rather than a runtime panic, because the closure's return type is checked against the field type.

This is the pattern clap's own cookbook uses for the same situation. From the typed_derive cookbook:

#[arg(
    long,
    default_value_t = 22,
    value_parser = clap::builder::PossibleValuesParser::new(["22", "80"])
        .map(|s| s.parse::<usize>().unwrap()),
)]
port: usize,

Same idea: the parser natively produces String, and .map() brings it to the field type.

If you want the check without the conversion

If ZeroF64 really should only ever be used with f64 fields, the cleanest thing is to make the field type match the parser rather than the other way round:

#[clap(long, value_parser = ZeroF64)]
n: f64,

That is trivially correct, but it does not give you the static guarantee you asked for in the general case. As far as I know there is no way today to get the compiler to reject value_parser = ZeroF64 on a usize field. .map() sidesteps it by making the mismatch impossible rather than by detecting it.

Practical note

Because the failure is a runtime panic on access rather than a parse error, it will not show up in a simple --help run. It only fires when the argument is actually read. A test that parses a representative set of arguments and touches every field is worth having if you use custom parsers, since it turns this class of mistake into a test failure rather than something a user finds.

[BergmannAtmet]

Actually the map idea was a good tip, but not in the way you used it (which actually makes things worse). And you have to remember to use maps on first writes for all value parsers. Then it only helps if a field type changes or when the attribute is copied around, but it's better than nothing.

#[derive(Parser, Debug)]
struct Cli {
    #[clap(long, value_parser=ZeroF64.map(|v: usize| v))]
    n: usize,
}

Maybe the deriver could add a typed_value_parser=ZeroF64 option that adds this mapping automatically!

[RenSolvyn]

You are right, and mine was actively worse than doing nothing. I compiled all the variants to be sure rather than guess, results below.

Why yours checks and mine does not

TypedValueParser::map takes F: Fn(Self::Value) -> T. The closure's input unifies with the parser's Value, its output with the field type. Your annotation constrains the input side, which is the side that matters.

Your version, mismatched types:

#[clap(long, value_parser = ZeroF64.map(|v: usize| v))]
n: usize,

error[E0631]: type mismatch in closure arguments
    = note: expected closure signature `fn(f64) -> _`
               found closure signature `fn(usize) -> _`
error[E0277]: the trait bound `MapValueParser<ZeroF64, {closure@...}>: TypedValueParser` is not satisfied

Exactly the static check you asked for, and the diagnostic names both types.

My version:

#[clap(long, value_parser = ZeroF64.map(|v| v as usize))]
n: usize,

Compiles clean. The input stays inferred as f64 and as silently narrows, so a genuine mismatch becomes a lossy cast at runtime. That is worse than the original problem, since at least the original panicked loudly.

A self-documenting variant, also verified

use std::convert::identity;

#[clap(long, value_parser = ZeroF64.map(identity::<usize>))]
n: usize,

error[E0631]: type mismatch in function arguments
error[E0277]: the trait bound
  `MapValueParser<ZeroF64, fn(usize) -> usize {identity::<usize>}>: TypedValueParser`
  is not satisfied

Same constraint, and the name states the intent: assert a type, convert nothing. Function pointers satisfy map's Clone bound.

Confirmed it does not false positive on correct usage either:

#[clap(long, value_parser = ZeroF64.map(identity::<f64>))]
n: f64,

Compiles and parses normally (parsed n = 0).

Full test matrix

Variant	Field	Result
ZeroF64.map(|v: usize| v)	usize	compile error (correct)
ZeroF64.map(|v| v as usize)	usize	compiles, silently narrows
ZeroF64.map(|v: f64| v)	f64	compiles
ZeroF64.map(identity::<usize>)	usize	compile error (correct)
ZeroF64.map(identity::<f64>)	f64	compiles and runs

Tested on rustc 1.75.0, clap 4.4.18.

Answering the original question

Yes, it is achievable today, with the boundary you already identified. The idiom catches:

• a field type changing while the parser stays the same
• the attribute copied to a field of a different type
• a parser's Value type changing underneath you

It does not catch a value_parser written without the .map at all. That gap cannot be closed from the call site, because only the deriver sees both the attribute and the field type.

On typed_value_parser

Worth opening as its own issue, and the compiler output above is the strongest supporting evidence: the constraint is already expressible in today's type system. The deriver would only be emitting a pattern that provably works, not requiring new machinery.

#4830 tracks the broad "compile time validation of value_parser types" problem and is worth linking, but a narrowly scoped attribute request with a working proof of concept is likely to move faster than the general one.

Thanks for the correction, the identity trick is a genuinely useful thing to know.

[epage]

@RenSolvyn your posts read as being copy/paste LLM responses. While I have not officially posted an AI policy, this is not good etiquette and continuing to do so will see you banned from the repo. See policies like https://github.com/rust-lang/regex/blob/master/AI_POLICY.md.

[epage]

Yes, this would be desired. The problem is that we have to Box<dyn ValueParser> the value parser in clap and I hadn't initially designed things to delay that so we could have access to the type of the TypedValueParser. This is something I want to fix in clap v5.

Looking, I'm not seeing a direct issue for this. #3864 covers a special case for this that may or may not be solved the same way.

#4830 is for the builder API and not the derive API.

[BergmannAtmet]

Should a dedicated issue be opened for this?