Generalized compile-time circuit signatures
Design document · English reading edition
RFCs record designs and changes. A proposal appearing here does not mean its feature is ready to use. Explore current language support
Status recorded in the original: Proposed
Bound original source · SHA-25633d6c9c1e33d5de596fc124a841a30f4bb01fc999d89814f45d5b9418858961c
Reading edition reviewed: 2026-10-02
Purpose and scope
Proposes circuit signatures with multiple disjoint register views and compile-time size parameters. The aim is source reuse and checked resource ownership.
Core design rules
const ...: Intarguments andQReg<E>widths are resolved at the call site.- Disjoint views of one physical register may be accepted; overlapping views are rejected.
- Specialization is deterministic and retains source mapping plus
adjoint, boundedctrlandpowsemantics.
Example from the original
This example illustrates the design recorded in the original. It is not by itself a claim of executable or stable support; check required options and the current version.
circuit entangle<const N: Int>(
control: QReg<N>,
target: QReg<N>,
theta: Angle
) {
for i in 0..N {
Ry(target[i], theta);
CNOT(control[i], target[i]);
}
}Limits and interpretation
- Runtime sizing, recursion, dynamic calls and measurement/training inside a generic circuit are outside this slice.
- A generic signature does not imply generic QPE/Simon/Shor readiness or larger simulation capacity.
Status and implementation boundary
The original is proposed. Generic signatures, oracle types and concrete circuit support are separate contracts; examine exact-version dependencies and current capabilities together.
| Review topic | Information to check |
|---|---|
| Source revision | SHA-256 digest bound to this reading edition |
| Availability | Current capability record and tool options |
| Evidence boundary | Model, size and interpretation limits above |