Skip to main content
NM-RFC-0015

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-256
33d6c9c1e33d5de596fc124a841a30f4bb01fc999d89814f45d5b9418858961c

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 ...: Int arguments and QReg<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, bounded ctrl and pow semantics.

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.

nm
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.

Table 1
Review topicInformation to check
Source revisionSHA-256 digest bound to this reading edition
AvailabilityCurrent capability record and tool options
Evidence boundaryModel, size and interpretation limits above