061 named expression params

○ Planned This feature is planned but not yet implemented.

Should use Pattern Branches instead of named Expression parameters. Pattern Branches are the better mechanism for this.

Failure Output

Showing last 10 of 12 lines

    |
 11 | ~[keyword|comptime|transform]pub tor operation {
    | ^

error[KORU010]: '_' is only legal as the body of a branch handler
  --> tests/regression/300_ADVANCED_FEATURES/310_COMPTIME/310_061_named_expression_params/input.kz:36:0
    |
 36 | |> _
    | ^
  hint: '_' has meaning only as `| branch [binding] |> _`. Outside a branch handler body — top-level void chain, split-pipeline tail — `|> _` is meaningless.

Code

// Test 310_042: Named Expression Parameters
//
// This test documents that multiple named Expression parameters in transforms
// are not yet fully supported. See README.md for details.

const std = @import("std");

~[comptime]

// Event with implicit Expression + named Expression parameter
~[keyword|comptime|transform]pub tor operation {
    expr: Expression,
    guard: Expression,
    program: *const Program,
    allocator: std.mem.Allocator
}
| transformed *const Program

~proc operation|zig {
    // Both expr and guard should be available as []const u8
    std.debug.print("[operation] expr='{s}' guard='{s}'\n", .{ expr, guard });
    return .{ .transformed = program };
}

// Usage: implicit expr + named guard Expression
~operation(1..N, guard: i > 100)

// Scaffold to make it compile
~tor dummy {}

~proc dummy|zig {
    std.debug.print("dummy\n", .{});
}

~dummy()
|> _

input.kz

Flows

flow ~operation click a branch to expand · @labels scroll to their anchor

operation (1..N, guard: i > 100)

← 060 tap as library 062 tap nested invocation →