Attribute Macro batch_task 

#[batch_task]

Apply to the BatchTask trait definition, an impl BatchTask<S [, K]> for T block, or — for less boilerplate — an inherent impl T { ... } block.

Use as #[cano::task::batch].

Two surface forms are supported on impl blocks:

1. Trait-impl form: #[task::batch] impl BatchTask<S> for T { type Item = I; type ItemOutput = O; ... } — user writes the trait header. The macro async-rewrites the BatchTask impl AND emits a companion impl Task<S> for T that delegates Task::run → run_batch.
2. Inherent-impl form: #[task::batch(state = S [, key = K])] impl T { async fn load(..); async fn process_item(..); async fn finish(..); } — the macro builds the impl BatchTask<S [, K]> for T header from the attribute args, infers type Item from the &T parameter of process_item and type ItemOutput from its return type, enforces that load, process_item, and finish are present (concurrency, item_retry, config, name may be overridden), and emits the same companion impl Task<S [, K]> for T.

On a trait definition (#[task::batch] pub trait BatchTask ...) the macro just performs the async-fn-in-trait rewrite.

Because a blanket impl<B: BatchTask<..>> Task<..> for B would conflict (E0119) with the analogous blanket impls for the other specialized task traits — a type can implement more than one — the companion Task impl is generated per-use-site rather than as a blanket.

Task::run always delegates to the ::cano::task::batch::run_batch free function (it is never inlined into the generated code) because the fan-out loop requires futures_util, which is not a direct dependency of external callers.