What causes "not implemented for dtype {:?}" in pola-rs/polars?

Pass a supported dtype to the builder instead of inferring it from data (e.g. use the correct Utf8/Binary/BinaryView dtype for BinaryArrayBuilder)

pola-rs/polars · error

not implemented for dtype

Error message

not implemented for dtype {:?}

What it means

The apply/with-physical-type macro in polars-utils panics when it encounters an Arrow DataType for which no corresponding physical type arm is implemented. In this case BinaryArrayBuilder receives a dtype outside the handled set of numeric/float types and hits the catch-all `dt => panic!("not implemented for dtype {:?}", dt)`. It signals that a dtype-dispatch operation lacks support for the given type.

Solutions

Pass a supported dtype to the builder instead of inferring it from data (e.g. use the correct Utf8/Binary/BinaryView dtype for BinaryArrayBuilder)
Add (or request) a macro arm for the missing dtype if the type is legitimately needed
Guard the call site: check the dtype against supported variants before constructing the builder

Example fix

// before
let b = BinaryArrayBuilder::<i64>::new(dtype); // dtype may be unsupported
// after
match dtype {
    ArrowDataType::Binary | ArrowDataType::Utf8 => {},
    other => panic!("unsupported builder dtype {:?}", other),
}
let b = BinaryArrayBuilder::<i64>::new(dtype);

Defensive patterns

Strategy: type-guard

Validate before calling

// Rust: check dtype support before building
fn supported(dtype: &ArrowDataType) -> bool {
    matches!(dtype, ArrowDataType::Binary | ArrowDataType::LargeBinary | ArrowDataType::Utf8 | ArrowDataType::LargeUtf8)
}

Type guard

fn is_binary_like(dt: &ArrowDataType) -> bool { matches!(dt, ArrowDataType::Binary | ArrowDataType::LargeBinary) }

Prevention

Always pass an explicit supported dtype to BinaryArrayBuilder::new
Whitelist dtypes before schema-driven builder construction
Check the dtype-dispatch macro's covered arms when adding new Arrow types

When it happens

Trigger: Constructing or operating on a BinaryArrayBuilder (or similar macro-dispatched builder) with an ArrowDataType that the macro does not cover, e.g. wrong dtype passed to BinaryArrayBuilder::new or a match dispatch over an unhandled type variant.

Common situations: Extension/FFI code creating builders with mismatched dtypes; schema-driven code feeding arbitrary dtypes into a fixed dispatch table; new Arrow dtype variants added before the dispatch arms are updated.

Related errors

AI-assisted analysis of pola-rs/polars@fe841f959e (2026-09-18). Data as JSON: /api/errors/aeff59f9f44f8863. Report an issue: GitHub.

Appendix: source

Thrown at crates/polars-utils/src/macros.rs:38

    $key_type:expr, | $_:tt $T:ident | $($body:tt)*
) => ({
    macro_rules! __with_ty__ {( $_ $T:ident ) => ( $($body)* )}
    use $crate::datatypes::DataType::*;
    match $key_type {
        Int8 => __with_ty__! { Int8Type },
        Int16 => __with_ty__! { Int16Type },
        Int32 => __with_ty__! { Int32Type },
        Int64 => __with_ty__! { Int64Type },
        Int128 => __with_ty__! { Int128Type },
        UInt8 => __with_ty__! { UInt8Type },
        UInt16 => __with_ty__! { UInt16Type },
        UInt32 => __with_ty__! { UInt32Type },
        UInt64 => __with_ty__! { UInt64Type },
        UInt128 => __with_ty__! { UInt128Type },
        Float16 => __with_ty__! { Float16Type },
        Float32 => __with_ty__! { Float32Type },
        Float64 => __with_ty__! { Float64Type },
        dt => panic!("not implemented for dtype {:?}", dt),
    }
})}

View on GitHub (pinned to fe841f959e)