Rule 6.1

Chapter 6, Declarations and resources Test

A resource must be written declare const x: uniform<T>, declare const x: storage<T>, declare const x: storage<T, "read_write">, or declare const x: <texture or sampler type>. It must have no initializer, and its binding slot is the source order of declare in the file. A resource is never declared with let: declare let x: storage<T> and declare let x: uniform<T> are both refused, and each refusal names the declare const form of the line it is on.

The rule text and the parts under it are the compiler's own English, as the design document writes them.

Rationale

declare is TypeScript’s own word for a value that exists elsewhere, which is what a host-owned resource is, and const is the only keyword that says anything true about one, since nothing rebinds the name.

Derives from

Variable and Value Declarations, Address Spaces, Shader Interface; surface §1, §7 and §15.

How it is verified

Checked by a test. A test, a gate script or a CI workflow names this rule, and the traceability check fails when a file listed below stops naming it.

Where the rule says the compiler enforces it:

TS8099 for a declare with a plain type (declare "x" must be uniform<T>, storage<T>, a texture, a sampler or override<T>.);
TS8099 for declare let x: storage<T> and for declare let x: uniform<T>, raised in src/compiler/ts/bindings.ts where the declaration’s keyword is already read, each sentence naming the declare const line to write instead;
TS8033 for a resource type without declare, whose sentence names the declare const form and, on a storage with no access mode of its own, the mode the KEYWORD asked for (let dst: storage<array<f32>> names declare const dst: storage<array<f32>, "read_write">, the same reading of the same keyword bindings.ts makes); a resource with no type argument names the shape storage<...>, since the type is one only the author knows;
examples/binding-declared.test.ts for the slot order.

The files that verify it at commit 26de7be8, each at the first line that names the rule:

Explained in

The sections of the surface document that explain this rule, at commit 26de7be8:

§1 Resources — declare

Error codes that enforce it

The diagnostic codes the rule names under Enforced by, or whose registry text names the rule:

TS8033 MODULE_VAR: A module variable (let x: workgroup<T>, let y: T = init, §24) declared or used where its address space forbids: a const with an address-space wrapper, a workgroup variable with an initializer, a type the space cannot hold (a texture, a runtime-sized array, an atomic in a per-invocation variable), an initializer that is not a constant, or a workgroup variable reached from a vertex or fragment entry (roadmap 0.2 item 5).
TS8099 UNSUPPORTED: UNSUPPORTED (TS8099) is the one deliberate exception to "sequential": it is the catch-all for a diagnostic whose site does not yet deserve its own code, so it stays parked past the sequential range instead of at its head.

Source

The rule at commit 26de7be8:

docs/language-design.md:384 (the design document)
reqs/rules/RULE-0601.md (its traceability item)

Edit this page Report a problem