Skip to content
ZOLO / TE190 Type · error

filtering iteration requires concrete non-linear elements and bindings

Compiler diagnostic TE190: filtering iteration requires concrete non-linear elements and bindings.

Why this fires

for case skips each element that does not match its pattern. The compiler must know that dropping a mismatch does not lose a resource that requires consumption. It also checks the types of values bound by the pattern, including string capture converters.

Use a concrete non-linear element type:

fn report(results: [Result<int, str>]) {
    for case .Ok(value) in results { print(value) }
}

Linear element types, generic T, Any, unresolved types, and structural fields with unknown ownership are not admitted. This also applies to wildcard filtering and patterns that happen to match every element: the explicit filtering form has the same ownership requirement for every pattern.

For linear values, use an ordinary loop and handle every branch with an explicit match, including consumption or cleanup of the values that are not selected. The compiler does not infer a cleanup protocol from a method name.

The structured suggestion is guidance with placeholders, anchored on the first pattern binding identifier when available. It does not rewrite ownership code automatically. A pattern without a binding uses its authored case keyword.

Ordinary for Point { x, .. } in values retains its existing mismatch panic. case remains usable as a variable, including for case in values and for case, value in entries.

When an unconstrained generic constructor leaves a type parameter unbound, annotate the collection explicitly, such as let results: [Result<int, str>] = [...]. The diagnostic includes the inferred element type to identify the missing context.

Global index

Find your way through Zolo

Try an idea

Start here

9 results

9 results

en