sxyazi/yazi · error

not a number

Error message

not a number

What it means

This error is raised by a generated Data-to-float conversion macro in yazi-shared. When converting a `Data` value into a float type (f32/f64), only Integer, Number, String, and Id variants are accepted — and Integer/Id only when losslessly representable; any other variant (Bool, Null, List, Map, etc.) hits the catch-all arm and bails with "not a number".

Solutions

  1. Inspect the Data value's variant before conversion and pass a genuine number or numeric string.
  2. If the source may be absent, default it (e.g. 0.0) before calling the API.
  3. For integer inputs that must stay exact, convert via the integer accessor instead of the float one.
  4. Fix the producer side (Lua script/config) so the field is always a number type.

Example fix

// before
let ratio: f64 = args.get("ratio")?; // Data::Bool -> "not a number"
// after
let ratio: f64 = match args.get::<Data>("ratio")? {
    Data::Number(n) => f64::from(*n),
    Data::Integer(i) => *i as f64,
    _ => 0.0, // or bail with a clear message
};
Defensive patterns

Strategy: type-guard

Validate before calling

fn as_float(d: &Data) -> Option<f64> {
    match d {
        Data::Integer(i) => Some(*i as f64),
        Data::Number(n) => Some(f64::from(*n)),
        Data::String(s) => s.parse().ok(),
        Data::Id(i) => Some(i.get() as f64),
        _ => None,
    }
}

Type guard

fn is_number_like(d: &Data) -> bool {
    matches!(d, Data::Integer(_) | Data::Number(_) | Data::String(_) | Data::Id(_))
}

Try / catch

let ratio: f64 = args.get("ratio").and_then(|d| as_float(d)).unwrap_or(0.0);

Prevention

When it happens

Trigger: Calling `Data::try_into::<f64>()` (or f32) on a Data value of variant Bool, Null, List, Map, or any other non-numeric type; also an Integer/Id value that loses precision on conversion falls through to this bail.

Common situations: Plugin arguments where a numeric option was omitted (Null) or mistakenly passed as a boolean or list; scripts driving yazi commands (e.g. scripts/moderate/main.js flows) supplying wrong-typed values for numeric parameters; config values intended as floats but provided as strings-of-other-shapes or nested tables.

Related errors


AI-assisted analysis of sxyazi/yazi@5f901b886b (2026-09-02). Data as JSON: /api/errors/b0695c06e7ffdd4a. Report an issue: GitHub.

Appendix: source

Thrown at yazi-shared/src/data/macros.rs:72

macro_rules! impl_into_number {
	($a:ty, $($b:ty),+ $(,)?) => {
		impl_into_number!(@impl ref   $a,  $a, $($b),+);
		impl_into_number!(@impl owned $a, &$a, $($b),+);
	};
	(@impl $kind:ident $t:ty, $a:ty, $($b:ty),+ $(,)?) => {
		$(
			impl TryFrom<$a> for $b {
				type Error = anyhow::Error;

				fn try_from(value: $a) -> Result<Self, Self::Error> {
					paste::paste! {
						Ok(match ref_or_owned!($kind, value) {
							$t::Integer(i) if *i == *i as $b as i64 => *i as $b,
							$t::Number(n) if f64::from(*n) == f64::from(*n) as $b as f64 => f64::from(*n) as $b,
							$t::String(s) => s.parse()?,
							$t::Id(i) if i.get() == i.get() as $b as u64 => i.get() as $b,
							_ => anyhow::bail!("not a number"),
						})
					}
				}
			}
		)+
	};
}

View on GitHub (pinned to 5f901b886b)