fee86adf2c
`tup[i]` where `i` folds to a compile-time integer (an `inline for` cursor or a literal) now reads the i-th tuple field with its CONCRETE type instead of failing with "cannot index a value of type '(…)'". A tuple's elements are heterogeneous, so there is no runtime element-indexing op — a comptime index lowers exactly like the `.N` field-access path (a `structGet` of the i-th field). A genuinely runtime index into a tuple value still falls through to the existing "cannot index a value of type" error (no single element type). A comptime index out of range gets a dedicated loud diagnostic. This is the read side `race` needs: pull the i-th `*Task(T_i)` handle out of a named-tuple param keeping its real type so field/method access on it resolves. Locked by examples/comptime/0652-comptime-tuple-cursor-index.sx.
5 lines
43 B
Plaintext
5 lines
43 B
Plaintext
[0] = 7
|
|
[1] = true
|
|
[2] = 2.500000
|
|
sum = 42
|