Draft language v0.2: arrays, main(args), string conversions, f-strings

[yunabe]

Summary

Starts the v0.2 cycle the same way v0.1 started: specification first. LANGUAGE_SPEC.md on main becomes the v0.2 draft — a status note marks it unimplemented and points at the v0.1.0 tag, which preserves the released v0.1 spec+compiler pair. Scope is the candidate list we accumulated during v0.1 development; everything else stays in §13.

Arrays (§3.1, §4.5, §8.4–8.6, §9.3, §10.2, §11)

• []T over any element type — arrays compose, so [][]i64 is a jagged .NET long[][] with chained indexing grid[i][j] (revised after review: the nesting restriction was a non-orthogonal special case that saved almost nothing). Fixed length, reference semantics, never null, mutable elements; the repeat form's sharing consequence ([[0; 3]; 2] shares one inner array) is specified with the fill-in-a-loop idiom.
• Creation: [e1, …, en] (with an expected []T, elements force to T; without one, elements resolve independently and must agree — so [] without an expectation is a compile-time error) and the repeat form [value; count] (value then count, each once; negative count is a runtime error).
• Zero-based i64 indexing (an expected-type position, like range endpoints) with runtime bounds errors on reads and writes; assignment targets extend to name[index] op= value.
• for x in array shares the range loop's variable rules; elements are read per iteration.
• len(array) -> i64 as a second compiler builtin — expression-valued, unlike print; len on strings deliberately stays out (§13).
• Deliberately absent: array ==/!= and print(array) — reference-vs-content ambiguity is postponed rather than answered wrongly.

fn main(args: []string) (§5.1)

Receives all arguments verbatim (no program name, no parsing, no usage exit), alongside — not replacing — the typed-parameter form. []string is the only array type allowed on main and cannot be mixed with typed parameters.

String conversions (§7)

i32/i64/f32/f64/bool(string) parse with exactly the §5.1 argument grammar (invariant, finite-only, case-insensitive bool) and fail with a runtime error — consistent with the section's other checked conversions, and making i64(string(x)) == x hold for integers. The main(args) + i64(arg) combination closes the loop that motivated typed main. A non-fatal try-style form is a §13 candidate.

Interpolated strings (§4.6)

f"x = ${x}", defined entirely by desugaring: text segments concatenated with string(hole) conversions, left to right. Per the earlier discussion: ${expr} only — a bare $ is a compile-time error (reserving $name shorthand, listed in §13), \$ escapes — and plain strings are untouched ($ stays ordinary, \$ invalid there). Holes take any primitive-typed expression, nested f-strings included.

Grammar (§12)

type gains the [] prefix; postfix indexing joins precedence level 1; array-expression; assignment-target; the for range clause becomes optional; interpolated-string joins literal with a lexical note.

Specification only — no compiler changes (dotnet test: 421 passed / 1 skipped, untouched). README's note now distinguishes "implemented v0.1" from "drafted v0.2", and CHANGELOG gains an Unreleased entry.

Points I'd flag for review as the debatable calls: reference semantics (vs. disallowing array assignment), the [value; count] evaluation order and its nested-array sharing, banning bare $, len rejecting strings, and keeping array equality/printing out entirely.

🤖 Generated with Claude Code

[yunabe]

The expected-type model is incomplete here. This rule makes let names: []string = [] valid, but Section 7 still says that an expected type applies only to a literal of the same numeric category. The repeat form also never says whether an expected []T is propagated to value, so a common case such as let xs: []i32 = [0; n] is currently undefined (or would infer []i64). Please update Section 7 to include array creation expressions and explicitly define contextual typing for the repeat form, including recursive propagation for nested arrays.

[yunabe]

This sentence contains two conflicting claims. First, “optional sign and exponent for numerics” implies that an integer conversion such as i64("1e2") accepts an exponent, whereas Section 5.1 permits exponents only for floating-point arguments; consider saying “an optional sign for numerics and an optional exponent for floating-point values.” Second, i64(string(x)) == x is not well-typed for an i32 value because mixed-width numeric comparisons are prohibited. Either restrict x to i64, or state the round trip using the matching integer type.