As Go platform owner, how do you decide which packages may import unsafe, and what do you demand for an exception?

## Why this is a policy question at all Every other rule in this area is a fact about the language. This one is not: `unsafe` is a legitimate tool, the standard library uses it, and the fastest implementations of some real problems need it. The decision is where the authority sits and what evidence moves it — which is a call somebody owns and can be overruled on. The reason it cannot be left to individual review judgment is specific. The rules for `unsafe.Pointer` conversions are subtle, mostly invisible in a diff, and failures do not surface at the site of the mistake: a stored `uintptr` produces a use-after-free somewhere else, minutes later, under load. A reviewer who does not already have those rules in their head will approve the code, and the reviewer who does have them cannot be in every review. ## The default and the mechanism Default deny, enforced by a check in CI that fails a build when a package outside the allowlist imports `unsafe`. Mechanical enforcement matters more than the list's contents: it turns a judgment made under time pressure into a conversation that happens before the code is written. The allowlist should name package paths, not directories or teams, and each entry should carry an owner's name, the reason, and a review date. A list with entries whose rationale nobody can reconstruct is worse than no list, because it launders the decision. ## What an exception has to show - **A benchmark, not an intuition.** The safe implementation must exist and must be measurably too slow at production scale, with allocation counts reported. Most requests die here honestly: someone tried the conversion first and never wrote the boring version. - **Containment.** All conversions live behind a small API in one package — a few accessor functions — rather than sprinkled through call sites. Containment is what makes the remaining review tractable and what makes removal possible later. - **Documented patterns cited.** Each conversion carries a comment naming which of the `unsafe` package's documented valid patterns it is. If the author cannot name one, that is the answer. - **Instrumented tests.** That package's tests run with `-race` in CI so the checkptr instrumentation validates conversions, plus `go vet` for its `unsafeptr` check, plus a test asserting any layout assumptions the code makes. - **An exit condition.** What would make this unnecessary — a compiler improvement, a standard-library addition, a change in the data volume. Without it, the entry is permanent by default. ## The two costs that are usually left out of the argument **Compatibility.** Ordinary Go code is covered by the Go 1 compatibility promise. Code that depends on the internal properties `unsafe` exposes is explicitly not. That is not theoretical: it means the person upgrading the toolchain inherits work from the person who wrote the fast path, possibly years later. The allowlist entry should make that ownership explicit, and the owner should be someone still accountable for the package. **Blast radius across an API boundary.** A package that uses `unsafe` internally and returns ordinary values contains its own risk. A package that returns pointers into a mapped region, or hands out values whose validity depends on a mapping staying open, has exported the lifetime rules to callers who cannot see them and will not read the doc comment. That is the case I refuse even with a good benchmark: change the API to return copies, bounds-checked offsets, or a handle with an explicit `Close`, and then re-argue the performance case against that shape. ## What to do with the code that already exists An inherited codebase will have `unsafe` in places nobody remembers. Inventory it, then triage in this order: conversions in exported APIs first, because their risk crosses a boundary; then anything storing a `uintptr` in a variable or field, which is the shape most likely to be outright wrong; then everything else. Delete what has no benchmark behind it — a safe rewrite that costs a few percent on a path nobody profiles is a trade worth taking every time. Grandfather the rest onto the allowlist with an owner and a date rather than pretending the ban applied retroactively. ## How you know the policy is working The allowlist gets shorter over time, exceptions arrive with benchmarks attached because people know they will be asked, and toolchain upgrades stop producing surprises from those packages. If instead the list grows and every entry's justification is that the safe version was never written, the policy is theatre and the honest move is to say so and re-decide.