Add struct literal field shorthand

[dmgcodevil]

Title

Add struct literal field shorthand

Summary

Support shorthand field initialization in struct literals when the field name matches an in-scope variable name.

This:

x: int = 1;
y: int = 2;
p: Point = Point { x, y };

should be equivalent to:

x: int = 1;
y: int = 2;
p: Point = Point { x: x, y: y };

Motivation

This is a small but high-value ergonomics feature.

It reduces repetition in a very common pattern and makes struct construction cleaner, especially when passing around local values with matching field names.

Proposed Behavior

In a struct literal, allow each field entry to be either:

• explicit: name: expression
• shorthand: name

Shorthand means:

Point { x, y }

desugars to:

Point { x: x, y: y }

Examples

Valid:

struct Point {
    x: int;
    y: int;
}

function main(): void {
    x: int = 3;
    y: int = 4;
    p: Point = Point { x, y };
    print(p.x);
    print(p.y);
}

Equivalent explicit form:

p: Point = Point { x: x, y: y };

Mixed explicit + shorthand should work:

label: string = "origin";
x: int = 0;
y: int = 0;
point: LabeledPoint = LabeledPoint { label, x, y: y + 1 };

Non-Goals

This feature does not change struct destructuring or pattern matching.

This feature should not allow arbitrary renaming in shorthand form. If the local variable name differs from the field name, the explicit form is still required:

Point { x: local_x }   // valid
Point { local_x }      // should not mean x: local_x

Suggested Implementation

Recommended approach: desugar shorthand during parsing / AST construction.

For example, parse:

Point { x, y }

into the same AST shape as:

Point { x: x, y: y }

This should keep type checking and code generation simpler.

Likely Files To Update

• src/grammar.pest
• src/ast.rs
• possibly src/type_checker.rs if needed
• possibly src/compiler.rs if parser desugaring does not fully normalize it

Parser / Grammar Notes

Current struct literal field grammar expects:

IDENTIFIER ":" expression

This should be extended so a field can be either:

• IDENTIFIER ":" expression
• IDENTIFIER

Recommended desugaring target:

• shorthand x becomes field ("x", Identifier("x")) or equivalent normal access expression

Acceptance Criteria

• Point { x, y } parses successfully
• shorthand and explicit forms can be mixed in the same literal
• shorthand behaves exactly like field: field
• existing explicit struct literal syntax continues to work unchanged
• type checking and compiled execution behave the same as explicit field initialization

Tests

Add at least:

1. Parser test for shorthand-only literal
2. Parser test for mixed shorthand + explicit fields
3. Compiler or runtime test proving shorthand produces the same result as explicit initialization
4. Negative test if needed for malformed syntax

Notes

Use existing Skunk syntax conventions:

• int, not Int
• full declaration form like p: Point = Point { x, y };