No way to join two arrays, so every program that needs one writes the same loop

[anderix]

Queued, not asked for — the freeze is the point and this is feature-shaped.
Filing it because five programs in a row wanted the same five lines.

There is no way to put two arrays together. += appends one element, and
handing it an array is refused:

$ cat j.lux
var a = [1, 2]
let b = [3, 4]
a += b

$ lux run j.lux
error: cannot add [int] to an array of int
  --> j.lux:3:1
 3 | a += b
     ^^^^^^
help: `lux learn arrays` — an array holds one type, so += has to match it

Verified against 0.19.2. The workaround is the same every time:

func joined(first: [int], second: [int]) -> [int] {
    var both: [int]
    for item in first {
        both += item
    }
    for item in second {
        both += item
    }
    return both
}

Where it came up

Writing a Texas Hold'em tutor, which needs a player's two cards and the board's
three, four, or five as one array before it can be scored, and needs it again
for the opponent, and again for every hand it deals in simulation. Also in a
maze, a hangman, and a rock-paper-scissors bot — anywhere a program builds one
list out of two it already has.

Every one of those wrote joined and moved on. It is not a hard function. What
it is, is the same function five times, which is the shape of a gap.

The obvious fix is the wrong one

a += b should stay refused. lux has arrays of arrays, and there the meaning
splits in two:

var grid: [[int]] = [[1, 2], [3, 4]]
let row = [5, 6]
grid += row          // append a row? or glue two grids?

Appending is what it means today and what a grid-building loop needs. If +=
also concatenated, that line would be ambiguous in a way no error message could
resolve, and the failure would be silent — the program runs, the grid is the
wrong shape, and the learner is debugging geometry. A language that refuses to
coerce a string into a number should not guess here either.

So the ask, if it is ever worth anything, is a named built-in rather than an
operator:

let all = joined(hole, board)

It reads as what it does, it cannot be confused with appending, and it goes
where length and split already live — split makes an array out of one
string, and this makes one array out of two.

The case against, which is real

Every built-in is a word a beginner has to meet, and the loop it replaces is
five lines a beginner should be able to write. Writing joined by hand is a
genuinely good exercise: it is a for loop, an accumulator, and a return, which
is most of what the functions card teaches. A language this size earns its size
by leaving that alone.

The counter is that the exercise stops being an exercise the second time you
write it, and by the fifth it is noise in the program that wanted the answer. My
own reading is that this sits just under the bar — worth recording, not worth
the clock.

[anderix]

Declined, and the material changed instead — 6e8edce.

Why not a built-in. Not because it is a convenience, which was this issue's own framing and is too weak a reason to close on. The accumulator loop — declare a var, walk with for, append with += — is lux's only idiom for building an array out of arrays it already has, and it has to be, because there is no map, no filter, no reduce, and no method chaining. Summing, filtering, finding a maximum, reversing, searching: all the same three moves. A joined built-in would lift that pattern out in one place and leave twenty neighbours untouched. It would not unteach the loop, since the learner still writes it everywhere else; it would only make the language inconsistent about when the loop is the answer. Rejecting keeps one rule.

The unlearning cost is real and already priced in. A Rust reviewer would flag an accumulator loop where [a, b].concat() exists, and Swift would rather see a + b — the same way Rust would rather see iter().sum() than a loop that adds. lux's stated bargain is that you relearn the syntax and keep the concept, and "build a new collection out of two you have" is the concept.

The argument that survives, and what it is really about. The workaround is not reusable: joining [Card] and later [Inst] means two copies, and "when the types differ, copy the function" is a habit all three targets punish. That is genuine, but it is an argument about generics, not about joining — contains on an array, indexOf and sorted sit in exactly the same position. A joined built-in would mask one instance of that gap and leave the class untouched. If it is ever worth closing it gets closed as itself, after 1.0.

And five occurrences is a maintainer's complaint, not a learner's. Four of the five programs named here are corpus programs written to exercise the language. A learner writes joined once, in one program, and it is a good exercise — a loop, an accumulator, and a return, which is most of the functions card. Milestone 13 already made this call in the same words: the missing pieces are walls a learner discovers and asks for, not gifts handed down ahead of the wish. No learner has asked.

What did change. The re-derivation complaint is fair, so the answer went into the material — and into the place that teaches the general move rather than the place that hands over one answer. A lux magic spell was considered and set aside: all twelve existing spells are I/O or crawl-world scaffolding, none is an algorithm recipe, and a join spell would be the first of a family with an obvious rest (sum, max, contains, reverse, sort) — the same one-exception-to-twenty objection, moved to the content layer.

Instead the functions more page gained a worked extraction. It taught packaged work, parameters, return and recursion, and its only example was factorial — manufactured, since nobody needs a factorial twice in one program — with no example anywhere of the move functions exist for. The page now shows two poker hands built inline with the loop written twice, names the signal (the second writing, not the first), gives the technique (read the copies beside each other; what differs becomes a parameter), and shows the same program with one joined called twice. Both versions print the same two lines, which is what makes it a refactor. The closing paragraph names the generics wall directly, so a learner meets it as something visible rather than something they trip over. arrays cross-references it, so someone arriving with the array question finds it.

One stale claim fixed on the way past. The scope note listed "string split" among the conveniences lux withholds, though split shipped in 0.18.0. It now names the line rather than a list: what earns a convenience is a learner who cannot proceed without it, which split was — a program reading what someone typed has no way through otherwise — and joining is not.

The freeze is untouched and still runs to 2026-09-05.