A row buffer both hands rows out and takes rows in — which member do you drop to make it single-directional?

## Why there is no in-place fix The buffer declares `take() returns T` and `put(value T)`. Those two mentions are on opposite sides, and the classification follows from the mentions rather than from intent: as long as both are present, the placeholder is pinned. No annotation, no parameter tweak and no naming convention changes that, because the checker is reading exactly those two signatures. The question therefore has a structural answer, not a clever one — **something has to stop mentioning the placeholder**, and the only choice you get is which side stops. ## Splitting along the direction of travel The usual move is not to delete anything but to redistribute it: - A **feed** type keeps the reading members. Its placeholder appears only as a result, so it is output-only, and a caller may hand it an instantiation over a more specific row type. - A **drain** type keeps the accepting member. Its placeholder appears only as a parameter, so it is input-only, and a caller may hand it an instantiation over a more general row type. - The concrete buffer implements both. At run time there is still one object holding one collection of rows; the split exists in the type surface, not in the data. The renderer then declares the surface it actually uses. A stage that only reads takes the feed; a stage that only writes takes the drain; a stage doing both names the buffer. Each declaration now advertises its direction truthfully, which is what gives its callers room. ## What each surface buys | surface | placeholder's position | what the caller may pass | what the caller may do | |---|---|---|---| | feed | output only | an instantiation over a more specific row type | read rows | | drain | input only | an instantiation over a more general row type | write rows | | buffer | both | the exact instantiation only | read and write | Read down the last two columns and the trade is plain: freedom for the caller is bought with capability on the reference. Every operation you keep on one surface costs the surface some of the substitution freedom it would otherwise have. ## Choosing which member to drop The choice is made at the call sites, not in the abstract: 1. Look at what each parameter of each consuming function does with the value. Reads only, writes only, or both. 2. Where it reads only, the accepting member is the one to drop from that parameter's type — the reads are what the parameter is for. 3. Where it writes only, the handing-back member goes, for the same reason in the other direction. 4. Where it genuinely does both, drop nothing and name the pinned type; forcing a split there just makes the call site take two references to the same object. The mistake to avoid is dropping the member the *type* uses least rather than the one the *parameter* does not need. A buffer whose accepting member is rarely called is not thereby a feed; the classification is about the surface a given parameter is declared with. ## What the caller loses Be honest about the cost in an interview, because a candidate who claims the split is free has not used it: - Code that reads and writes the same buffer through one reference has to name the both-directions type, and gets no substitution freedom at all for its trouble. - The type surface grows: two extra declarations, and a reader has to learn which one each function wants. - A caller that needs both surfaces of the same object either passes it twice or passes the concrete type, which defeats the point for that call. ## What is not in scope here Two neighbouring subjects are easy to drift onto and both belong elsewhere. *Why* a type you can both read and write has to be pinned in the first place — and the classic design that made a built-in container an exception and pays for it with a check at run time — is its own topic. So is the question of where a direction is written down: once on the declaration, or separately at each use, which changes what a split buys you and is the reason some type systems need the split less often than others. The point that belongs here is narrower: given a type with a mention on each side, the single-directional version is obtained by removing one of them, and which one you remove is decided by what the call site does with the value.