iced-rs/iced · critical

not implemented

Error message

not implemented

What it means

iced_futures ships pluggable async executor backends (tokio, smol, thread-pool) behind Cargo features. When none is enabled, `backend::Executor` resolves to the null backend: `spawn` silently drops futures and `block_on` is a stub that panics with `unimplemented!()`. The panic fires the first time anything tries to drive a future to completion on that executor.

Source

Thrown at futures/src/backend/null.rs:17

//! A backend that does nothing!
use crate::MaybeSend;

/// An executor that drops all the futures, instead of spawning them.
#[derive(Debug)]
pub struct Executor;

impl crate::Executor for Executor {
    fn new() -> Result<Self, futures::io::Error> {
        Ok(Self)
    }

    fn spawn(&self, _future: impl Future<Output = ()> + MaybeSend + 'static) {}

    #[cfg(not(target_arch = "wasm32"))]
    fn block_on<T>(&self, _future: impl Future<Output = T>) -> T {
        unimplemented!()
    }
}

pub mod time {
    //! Listen and react to time.
}

View on GitHub (pinned to 2cffa99b39)

Solutions

  1. Enable an executor backend feature on iced_futures: `iced_futures = { features = ["tokio"] }` (or "smol" / "thread-pool")
  2. If you use the iced facade crate, enable its "tokio" (or "smol") feature instead of re-declaring iced_futures with default-features = false
  3. Verify the dependency graph keeps an executor enabled: `cargo tree -i iced_futures -f "{p} {f}"`
  4. If you must stay executor-free, drive futures with your own runtime and never call block_on on the null Executor

Example fix

// before
iced_futures = { version = "0.13", default-features = false }
// after
iced_futures = { version = "0.13", default-features = false, features = ["tokio"] }
Defensive patterns

Strategy: fallback

Validate before calling

# CI sanity check: confirm an executor feature survives the dependency graph
cargo tree -i iced_futures -f '{p} {f}' | grep -E 'tokio|smol|thread-pool' || echo 'NO EXECUTOR FEATURE ENABLED'

Try / catch

let outcome = std::panic::catch_unwind(|| executor.block_on(app_future));
if outcome.is_err() {
    eprintln!("block_on panicked: is an iced_futures executor feature (tokio/smol/thread-pool) enabled?");
    std::process::exit(101);
}

Prevention

When it happens

Trigger: Calling `Executor::block_on` (directly, or via an iced entry point that runs the event loop to completion) when iced_futures is compiled with `default-features = false` and no `tokio`/`smol`/`thread-pool` feature. Note that on the null backend `spawn` is also a silent no-op, so futures never running is the earlier symptom.

Common situations: Setting default-features = false to slim down iced and forgetting to re-enable an executor; version upgrades that renamed or re-gated executor features; a workspace where another crate's dependency on iced_futures strips optional features via unification; native code accidentally calling the cfg(not(wasm32)) block_on path.

Related errors


AI-assisted analysis of iced-rs/iced@2cffa99b39 (2026-08-16). Data as JSON: /api/errors/24a9c01241be893c. Report an issue: GitHub.