Implementation plan for RFC #77: Assign Param Syntax (constructors only)

[SeanTAllen]

This is a revised implementation plan for RFC #77 (issue #4318), scoped to constructors only. The previous plan (#4985) included fun and be methods, but the RFC's motivation and examples all focus on constructors, and let fields (the primary use case) can only be assigned once, making fun/be support only useful for var fields — something the RFC never discusses.

What this is

Assign params let you write this.field_name in a constructor parameter position. The compiler infers the type from the field declaration, generates a hygienic name for the actual parameter, and prepends field = consume param to the constructor body. The whole thing is sugar — it's gone by the time the scope pass runs.

The before/after tells the story:

// Before: 6 lines of ceremony
class Foo
  let name: String
  let age: U32
  new create(name': String, age': U32) =>
    name = name'
    age = age'

// After: the compiler does the boring part
class Foo
  let name: String
  let age: U32
  new create(this.name, this.age) => None

You can mix assign params with regular params and give them default values:

new create(label: String, this.age, this.name = "unnamed") =>
  do_something_with(label)

Implementation approach

The implementation is a new token type (TK_ASSIGN_PARAM) that lives between the parser and sugar passes. The sugar pass replaces every TK_ASSIGN_PARAM with a normal TK_PARAM plus a consume-based assignment at the top of the constructor body. Everything downstream sees vanilla parameters.

Parser

A new assignparam rule handles this.field_name [= default]. To keep assign params out of FFI parameter lists (which share the params rule), I'm adding a methodparams rule that accepts both regular and assign params, used only in method declarations. The original params rule stays untouched for FFI.

The parser accepts assign params in any method's parameter list at the grammar level. The constructor-only restriction is enforced in the sugar pass, where fun and be methods with assign params get a clear error: "assign parameters are only allowed in constructors." This gives a better error message than rejecting at parse time, where the context for a good message isn't available.

Sugar pass

A new sugar_assign_params function runs in sugar_new (and in sugar_be/sugar_fun just for error reporting), after docstring extraction but before check_method.

For each assign param in a constructor, it:

1. Looks up the field in the enclosing type
2. Generates a hygienic ID (the $0$1 style names from package_hygienic_id)
3. Duplicates the field's type for the parameter
4. Builds a replacement TK_PARAM and swaps it in
5. Prepends field = consume $hygienic_id to the body

Named arguments are excluded naturally since hygienic names can't be written at call sites.

Field initializer interaction

There's a coupling between sugar_entity (which prepends field = init_value to all constructor bodies for fields with default values) and the assign param transformation. If a field has both a declaration-site initializer and an assign param, the assign param wins — sugar_assign_params removes the field initializer from the body to prevent double-assignment errors on let fields.

Cap lifting for sendable contexts

Actor constructors and iso/trn/val class constructors require sendable parameters. When a field has a non-sendable cap, the param type gets lifted: ref → iso, trn → iso, box → val. For unqualified types (where the cap is TK_NONE at sugar time), it conservatively lifts to iso. For complex types like type aliases where the cap isn't directly accessible, the type is left as-is and the existing flatten_sendable_params check reports a clear error.

Key design decisions

• Constructor-only scope. The RFC's motivation and examples are all constructors. Extending to fun/be is a separate decision. Using assign params in fun or be produces a clear error.
• Separate token type (TK_ASSIGN_PARAM) rather than a flag on TK_PARAM. The treecheckdef can validate it, and it's unambiguous during the parse → sugar window.
• No auto-promotion of field initializers to param defaults. If you want a default on your assign param, write it explicitly.
• Duplicate detection. Two assign params targeting the same field is an error.
• FFI isolation. A separate methodparams parser rule keeps assign params out of FFI declarations.

Differences from the broader plan (#4985)

• Assign params restricted to constructors; fun/be get an error
• constructor_needs_sendable replaces method_needs_sendable, scoped to match only what the flatten pass checks (class + actor constructors)
• remove_field_init_from_body no longer needs a constructor guard
• Error tests added for fun and be usage

Files touched

The change spans the parser (parser.c, token.h, lexer.c, treecheckdef.h, frame.c) and the sugar pass (sugar.c). Tests go in parse_entity.cc, sugar.cc, badpony.cc, and test/full-program-tests/. Plus an example program and release notes.

[SeanTAllen]

The broader plan that includes fun and be methods is at #4985.

[SeanTAllen]

Closing. We want the fun/be as well.