Forty teams implement your published formatter slot — which edits to its declared type leave every existing implementation valid?

You own a published cell-formatter slot: one amount in, display text out, implemented by forty teams you do not control. The slot has to change. Which edits can you land without a coordinated migration, and which ones are a migration whatever you call them? ## Two sides, two rules A function type sits between two parties, and the rule for what each may do runs in opposite directions. - An **implementation** may accept wider than the slot promises and return narrower than it promises. It may do more than asked and deliver something more specific. - A **declaration** may promise to pass narrower and promise to accept wider. It may ask for less than before. The two are the same principle seen from opposite ends. Substitution is always safe in the direction of *demanding less and guaranteeing more*, and which concrete edit that corresponds to depends on whether you are the one making the promise or the one meeting it. Reasoning from a remembered rule about implementations, applied to a declaration, gets you exactly the wrong answer — which is why this question separates people who memorised the rule from people who can re-derive it. ## The four edits | Edit to the slot | Effect on existing implementations | Effect on the renderer | |---|---|---| | Narrow the parameter type (pass less) | safe — they already handle the narrower set | it must now guarantee it never passes the excluded values | | Widen the result type (accept more) | safe — what they return is still accepted | every place consuming the result must cope with more | | Widen the parameter type (pass more) | breaks — they meet values they were never written for | none up front; the cost lands on the teams | | Narrow the result type (demand more) | breaks — they return something too general | none up front; the cost lands on the teams | The pattern is worth stating outright: **the two safe edits are the two that move work onto you**, and the two breaking edits are the two that look free from where you sit. That is not a coincidence — it is the whole content of the rule. ## Arity is the edit with no safe direction Adding the row as a second argument is not a widening or a narrowing; it produces a different type. No substitution rule rescues it. An implementation written for the old count survives only where the calling convention happens to discard the surplus, and relying on that turns a contract change into an invisible one. Treat an arity change as a migration from the start. The usual way to run one without freezing forty teams: 1. **Publish the new slot beside the old one**, so nothing breaks on the day of the change. 2. **Adapt at the registration point.** Every implementation still on the old shape is wrapped once, centrally, into the new arity, so the teams' own code need not change immediately. 3. **Move teams across on their own schedule**, with the wrapper as the thing that tells you who is left. 4. **Retire the old slot** when the wrapper has no users, and delete the wrapper with it. ## Choosing the shape you can live with When you first publish a hook you are choosing which future edits will be cheap. A slot declared with a **wide parameter and a narrow result** is demanding of implementers — they must handle everything and produce something specific — but it leaves you room, because both safe edits are still available to you later. A slot declared with a **narrow parameter and a wide result** is easy to implement today and has spent its room: the only edits left are the breaking ones. There is no free choice here, only a decision about who pays and when. The reason it is a senior question is that both answers are defensible and the failure mode is not noticing there was a decision. ## What the renderer pays for the safe edits The safe edits are not costless — they are costless **to implementers**. Narrowing the parameter type means the renderer must now guarantee it never passes the values it has excluded, which may be real work at the call site. Widening the result type means every place that consumed the old, narrower result must now cope with a broader one, and that work is inside your own code where you can do it in one change. That is the trade a published contract buys: keep the cost where you control the schedule.