Compile-Time Evaluation

Compile-Time Evaluation Uses Ordinary Sec Semantics

Semantic CTE preserves the normal language rules for:

• arithmetic and comparisons;
• boolean expressions;
• control flow;
• function calls and return;
• Result and Option;
• try;
• assert and panic semantics;
• ownership, move and copy;
• borrowing and references;
• destruction and defer;
• concrete generic callable semantics;
• property and method resolution;
• nominal type identity.

CTE does not introduce a second integer model, a second ownership model or a second error model.

Sec 0.1 Has No const fn or comptime Sub-Language

Sec 0.1 does not introduce source forms such as:

const fn
comptime fn
comptime expression
comptime block
compile-time namespace
IsCompileTime()

An ordinary function may run at runtime in one call and during semantic CTE in another.

fn CalculateSize(scale: uint) uint {
    return 1024 * scale
}

The source function itself is not permanently classified as a compile-time function.

It also cannot observe merely that the compiler happens to be evaluating it during CTE.

Sec Distinguishes Two Compile-Time Context Classes

The compiler distinguishes:

PlanTimeRequiredContext
SemanticCompileTimeRequiredContext

These are compiler-semantic terms, not Sec source declarations.

Plan-Time Evaluation Is Deliberately Restricted

Plan-time evaluation exists for source-selection and similar compilation-plan decisions.

It may use only inputs explicitly allowed by the owning rule, such as:

• literals;
• typed configuration parameters;
• canonical target/platform facts available at plan time;
• restricted operators;
• compiler-known identities explicitly made available by that grammar.

Plan-time evaluation cannot call arbitrary ordinary functions whose availability or body depends on the source graph that the same evaluation is trying to select.

This prevents phase cycles.

@target and @when are the main user-visible plan-time cases and are covered in chapter 38.

Semantic CTE Can Execute Ordinary User Functions

A normal user-defined function may execute during semantic CTE when:

• the function is semantically valid;
• all required arguments are compile-time values;
• the concrete executed path uses only CTE-permitted operations;
• generic identities are concrete where required;
• evaluation terminates within compiler resource limits.

fn MakeExtent(base: uint, multiplier: uint) uint {
    return base * multiplier
}

let BufferLength := MakeExtent(64, 8)

No special function modifier is required.

Required CTE and Optional Constant Folding Are Different

A language construct may require compile-time evaluation. In that case, CTE must succeed according to the language rules.

Separately, the optimizer may choose to evaluate ordinary runtime expressions early:

fn Work() void {
    let value := 10 * 20
}

The expression above has ordinary runtime semantics. The compiler may fold it to 200, but that optimization is not required CTE.

Disabling optional folding must not make an otherwise valid runtime program invalid.

The Owning Language Rule Defines Required Contexts

CTE itself does not decide that every “constant-looking” expression must run during compilation.

The rule owning a source construct defines:

• whether compile-time evaluation is required;
• whether the context is plan-time or semantic CTE;
• the required result type;
• the legal value domain;
• whether static materialization is required;
• which compiler-known inputs are available.

Examples of semantic CTE contexts include, where their owning rules permit expressions:

• module/static initializers that must be established during compilation;
• fixed array extents;
• static shaped extents and ranks;
• register widths and compile-time field values;
• explicit enum values;
• other declaration/type metadata explicitly requiring a semantic compile-time value.

Generic constraint checking is compile-time semantic analysis, but it is not itself automatically a semantic CTE request.

Static Initializers May Require Semantic CTE

fn CalculateBufferSize() uint {
    return 4096
}

let BufferSize := CalculateBufferSize()

When the owning static rule requires the initializer to be established during compilation, the expression is a semantic compile-time-required context.

A mutable static may likewise have a compile-time-established initial value:

fn CalculateInitialRetryCount() int {
    return 3
}

let mut RetryCount: int := CalculateInitialRetryCount()

After program initialization, RetryCount is ordinary mutable runtime state. Knowing its initial value at compile time does not make later reads CTE-safe.

If a required initializer cannot be evaluated, the compiler must not silently replace it with a hidden runtime initializer call.

Ordinary Local Expressions Stay Ordinary Runtime Expressions

fn Work() void {
    let value := 10 * 20
}

This binding is not CTE-required merely because its value is easy for the compiler to determine.

A nested source position inside a runtime function may still be CTE-required if the owning construct requires it, such as a fixed type extent.

Compile-Time Results Are Typed Sec Values

Successful semantic CTE produces a value with a canonical Sec type identity and a semantic value.

Conceptually:

uint32 with value 42

SortOrder[User] with value SortOrder.Ascending

Point with value {
    X: 10,
    Y: 20,
}

Nominal identity remains part of the value. Two values with the same machine representation do not become the same Sec type.

CTE Uses Sec Target Semantics, Not Compiler-Host Semantics

Compile-time values are not defined by:

• host-language object representation;
• compiler-host pointer width;
• host integer width;
• host endianness;
• host ABI;
• host memory addresses.

This is essential during cross-compilation.

Target-dependent semantic facts may legitimately differ between compilation plans, but they come from the selected Sec target plan rather than from the machine running the compiler.

Types Are Not First-Class CTE Values

Sec 0.1 does not introduce a general runtime or compile-time metatype such as:

Type
TypeInfo

A generic type parameter is a semantic type parameter, not an ordinary CTE value.

The CTE system itself does not add a TypeOf-style general facility.

CTE Does Not Automatically Create Reflection

The compiler knows many facts about a program, but that knowledge is not automatically exposed as source-level iterable reflection.

CTE does not automatically expose lists of:

• fields;
• methods;
• properties;
• attributes;
• interfaces;
• enum declarations;
• union declarations;
• modules;
• symbols;
• source locations;
• compiler IDs;
• Semantic IR;
• MLIR.

Individual compiler-known facts may be exposed when another language rule deliberately defines a concrete user-facing surface.

CTE Produces Values, Not New Declarations

Semantic CTE cannot create, insert, remove or rewrite source declarations.

It cannot synthesize new:

• functions;
• types;
• fields;
• methods;
• properties;
• enum members;
• union variants;
• interfaces;
• imports;
• modules;
• generic declarations.

A string produced during CTE remains a string value. It is not reparsed as Sec source merely because its contents happen to look like Sec code.

SizeOf Is a Compiler-Known Property

Canonical source forms are:

let valueSize: uint := value.SizeOf
let typeSize: uint := TypeName.SizeOf

The global-function form is not canonical:

SizeOf(TypeName)    // invalid canonical form

A SizeOf result is determined for the active concrete compilation plan.

Target-sized semantic types remain the same Sec types even when their physical size differs between plans.

CTE Does Not Add Implicit Generic Introspection

Generic template validity remains governed by declared generic constraints.

CTE does not introduce generic mechanisms such as:

if T == int
IsCopyable[T]()
Implements[T, Interface]()
HasMethod[T](...)

A specifically defined compiler-known property does not imply a general structural introspection system for generic source.

CTE Does Not Automatically Introduce Value Generics

The existence of compile-time values does not by itself make arbitrary values legal generic arguments.

Sec 0.1 type generics remain governed by the Generics chapter.

Const/value generic parameters require their own normative language rules and are not introduced merely by this CTE system.

CTE Legality Is Path-Sensitive

A function may contain runtime-only behavior on a branch that the concrete CTE invocation does not execute.

fn SelectValue(useDefault: bool) int {
    if useDefault {
        return 10
    }

    return ReadFromRuntimeSource()
}

SelectValue(true) may be valid during semantic CTE even when ReadFromRuntimeSource() is forbidden during CTE.

SelectValue(false) is not CTE-evaluable if that executed call requires a forbidden effect.

Semantic CTE Can Perform Real Computation

Subject to ordinary Sec legality and compiler resource limits, CTE may execute:

• arithmetic and comparisons;
• boolean logic;
• local immutable state;
• local mutable state;
• if, switch and match;
• for and while;
• ordinary function calls;
• concrete generic function calls;
• aggregate construction;
• Result and Option;
• try;
• assert and panic semantics;
• transient allocation;
• move, copy and borrowing;
• destruction and defer.

Local mutation during CTE is valid. It does not create persistent mutable compiler-global or program-global state.

CTE Cannot Read or Mutate Ordinary Mutable Runtime Static State

A mutable static may have a compile-time-established initial value, but that does not make later runtime storage reads deterministic CTE inputs.

Immutable compile-time-established values may be read where visibility and dependency rules permit it.

This separation preserves deterministic evaluation and safe caching.

Ambient and External Runtime Effects Are Forbidden When Executed

Semantic CTE may not execute ordinary ambient operations such as:

• filesystem I/O;
• network I/O;
• ambient environment-variable access;
• ambient current time;
• ambient entropy or randomness;
• target memory access;
• MMIO;
• volatile access;
• atomic operations;
• memory barriers;
• task, thread, channel or scheduler operations;
• foreign calls;
• system calls unless another canonical rule explicitly models a pure compiler-known semantic equivalent.

A deterministic pseudo-random algorithm using only explicit compile-time values is ordinary computation and is not ambient randomness.

Explicit canonical CompilationPlan facts are likewise not ambient host state.

unsafe Does Not Expand CTE Capabilities

Entering an unsafe source context does not itself make CTE invalid.

It also does not grant permission to:

• dereference arbitrary host memory;
• access target physical memory;
• access MMIO;
• call arbitrary foreign code;
• smuggle compiler-host addresses into program values.

An unsafe operation executed during CTE must have deterministic canonical CTE semantics.

Semantic CTE May Allocate Transient Evaluator Storage

Compile-time code can build temporary dynamic structures while computing a value.

This allocation:

• belongs to the compiler evaluator;
• does not consume target runtime heap capacity;
• does not mutate target allocator state;
• does not require target allocator startup;
• does not create runtime allocator generations;
• does not make compiler-host addresses into target addresses.

The implementation may use host allocations, an evaluator arena or another internal strategy. That implementation choice is not Sec language semantics.

Transient CTE Allocation Does Not Mean Runtime Allocator Objects Are Available

An operation that semantically interacts with a runtime allocator, Arena provider or another explicit runtime allocation context is not automatically legal during CTE.

The compiler may not silently substitute its private evaluator allocator for an explicit allocator resource supplied by the source program.

Another canonical rule may define a specific compile-time semantic equivalent, but such behavior must be explicit.

Ownership Rules Apply During CTE

A compile-time-created owning value may be:

• moved;
• borrowed;
• destroyed;
• used by defer;
• conditionally available;
• partially moved where ordinary Sec rules permit it.

Compile-time values are not automatically copyable.

Copy and move behavior follows the concrete Sec type exactly as it would at runtime.

Destruction Happens During CTE When Source Semantics Reach It

CTE-local owned values follow ordinary deterministic destruction semantics.

A destructor executed during CTE must itself use CTE-permitted operations.

Compiler-internal reclamation of evaluator memory is separate from observable Sec destruction.

If the compiler aborts one evaluation because a resource limit is reached, it is not required to continue arbitrary source-level cleanup after that external evaluator abort, though compiler-owned resources must still be reclaimed safely.

Safe References and Borrows May Exist During CTE

Ordinary Sec lifetime, aliasing, mutable-borrow and reborrow rules apply.

The evaluator may represent compile-time reference identity abstractly. Correctness must not depend on a numeric compiler-host address.

A CTE-local reference cannot escape into a runtime artifact merely by preserving its evaluator identity.

If a runtime/static reference is needed, another owning storage/materialization rule must create a valid new program identity.

Raw Pointers During CTE

Raw pointers to evaluator-local storage are possible only where ordinary raw-pointer and unsafe rules permit them and where deterministic CTE semantics are defined.

Numeric host pointer addresses must not escape as compile-time program values.

Explicit target address values are a separate semantic category. They may be consumed as metadata when the owning platform rule permits it.

Semantic CTE must not dereference target hardware memory.

Compile-Time Evaluability and Static Materialization Are Different

A value may be completely and successfully computed during CTE but still be unsuitable for direct embedding as a program/static value.

Conceptually the compiler distinguishes:

CompileTimeEvaluable
CompileTimeMaterializable

These are compiler terms, not Sec declarations.

Evaluation happens first. The owning language construct then validates the typed value and, if required, materialization is validated separately.

A materialization failure is not the same as an evaluation failure.

Materializable Values

Ordinary scalar values may be materialized when their concrete type has a defined static representation.

Examples include, where legal:

• bool;
• integers;
• floating-point values;
• rune;
• enum values;
• named scalar values;
• unit values.

Fixed aggregates may also materialize recursively, including:

• fixed arrays;
• structs;
• unions;
• Option;
• Result.

Immutable strings may be materialized where the string/storage rules define a valid target representation.

Materialization preserves nominal type and active variant identity.

Dynamic Owning Collections May Be CTE-Evaluable Without Being Materializable

A semantic CTE function may temporarily construct a dynamic collection such as:

list[T]
map[K, V]

if the executed operations are CTE-permitted.

Sec 0.1 does not automatically define static artifact materialization for every heap-backed dynamic owner merely because the evaluator can create it.

A value may therefore be:

CTE-evaluable
but not statically materializable

Views and Slices Need Valid Runtime Backing Before They Can Materialize

A slice or view may be used transiently over evaluator-local storage during CTE.

That view cannot be embedded into the resulting program unless its backing storage receives a valid static/runtime identity according to another canonical rule.

The evaluator's private pointer is never preserved as the runtime backing address.

Static Materialization Is Checked Recursively

When a CTE value must become program storage, the complete reachable value graph is validated.

The compiler checks:

• the concrete type has defined static materialization;
• every stored subvalue is materializable;
• no evaluator-local address escapes;
• no evaluator-local generation/liveness identity escapes;
• no unsupported cyclic evaluator object graph escapes;
• required target relocations and static references are legal.

Sec 0.1 has no implicit static heap model for arbitrary cyclic evaluator object graphs.

A Materialized Value Receives a New Program Identity

A successfully materialized result becomes ordinary program storage/value according to its owning storage rule.

The runtime/static object is not the same object as the evaluator-local object that computed the value.

Evaluator-local lifetime, generation and host-address identity do not survive merely because the semantic value survives.

Required Compile-Time Values Form a Dependency Graph

Evaluation order follows semantic dependencies rather than textual source order.

A declaration does not need to appear earlier in the file merely because it is used during required CTE, provided ordinary Sec name resolution makes it visible.

Independent required evaluations may be reordered or evaluated in parallel by the compiler. Such scheduling is not observable in Sec semantics.

Compile-Time Value Dependency Cycles Are Invalid

let A := B + 1
let B := A + 1

Neither value can be established without first establishing itself transitively.

The compiler diagnoses the semantic dependency cycle instead of recursing indefinitely.

Recursive Functions Are Not Automatically Dependency Cycles

Ordinary recursion and mutual recursion may execute during semantic CTE.

A recursive call-stack cycle is different from a compile-time value dependency cycle.

Recursive CTE is valid when the concrete evaluation terminates within the compiler's resource budget.

Dependencies Can Cross Values, Types and Layout

A semantic cycle may look like:

layout of Packet
    -> PacketSize
    -> CalculatePacketSize()
    -> layout of Packet

The compiler must detect such a cycle.

CTE does not invent placeholder layouts or speculative fixed-point behavior unless another owning rule explicitly defines such semantics.

Public Functions May Execute During CTE Across Module Boundaries

A source-accessible public function can be called during semantic CTE from another module.

Cross-module execution requires compatible semantic execution information for the called body.

A binary ABI signature alone is insufficient when compile-time execution needs the function body.

Separate-compilation artifacts may therefore carry canonical semantic bodies or an equivalent evaluator representation.

Cross-Module CTE Does Not Bypass Source Visibility

Compiler availability of semantic bodies is not source visibility.

Public, module-internal and source-file-private declarations keep their ordinary rules.

An imported module may directly call only declarations visible to that source.

A public function being evaluated may internally call already-resolved private helpers from its origin scope because those calls were legal in the origin source. That does not make the helpers importable from outside.

Generic Code Executes Only as Sufficiently Concrete Semantic Instances

CTE uses the same canonical concrete generic specialization identity as runtime semantic use.

It does not create a second “compile-time specialization” identity.

Unresolved runtime-like generic parameters cannot reach an operation that requires fully concrete semantic behavior.

Monomorphization remains responsible for specialization demand, identity, deduplication and physical realization.

Result.Err(...) Is a Successful CTE Value

fn Parse(...) Result[int, ParseError] {
    ...
    return Err(ParseError.InvalidDigit)
}

If semantic CTE evaluates the function and it normally returns Err(ParseError.InvalidDigit), evaluation succeeded.

The resulting Sec value happens to be the error state of a Result. That is not a compiler CTE failure.

Ordinary try semantics remain ordinary Sec semantics during CTE.

assert, Panic and Failed Semantic Operations

Assertions execute during semantic CTE.

If a required evaluation reaches a failed assertion, the compile-time evaluation fails.

Reaching a panic/fatal semantic operation likewise fails the required evaluation.

Other reached semantic failures may include:

• division by zero;
• invalid shift;
• checked numeric failure;
• bounds violation;
• invalid conversion;
• named-type contract violation.

The owning language rule still determines the exact user-facing error and meaning.

Loops and Recursion Are Allowed, but Evaluation Is Resource-Bounded

Sec 0.1 does not require the compiler to statically prove termination before semantic CTE.

Instead, the compiler imposes finite resource limits.

Canonical resource categories include:

ExecutionSteps
CallDepth
TransientMemory
AggregateValueSize

These are compiler-semantic categories, not Sec enum members.

Wall-clock time is not a canonical deterministic language budget. An implementation may use an emergency watchdog to protect the compiler process, but that watchdog is not Sec semantics.

Reaching a resource limit does not prove that the source expression is non-terminating. A larger permitted budget may succeed.

Transient-memory exhaustion during CTE is a compiler resource outcome, not target runtime out-of-memory behavior.

CTE Is Deterministic

With the same compatible compilation plan, semantic inputs and sufficient resource budget, CTE must produce the same semantic value or semantic failure independent of:

• source-file discovery order;
• compiler thread scheduling;
• hash-map iteration order;
• which independent CTE request happens to run first;
• compiler-host memory addresses.

Explicit target inputs may legitimately make results differ between compilation plans.

Ambient host filesystem, environment, time and entropy are never hidden semantic inputs.

Successful Evaluation Is Followed by Owning-Context Validation

A CTE expression can evaluate successfully but still produce a value invalid for the source construct that requested it.

Examples:

• an array extent evaluates to an integer outside the legal extent domain;
• @when does not yield bool;
• an enum explicit value does not fit the backing type;
• a static initializer is not assignable to its declared type;
• a register width evaluates outside the legal width domain.

Those are errors of the owning language construct, not evidence that the evaluator could not execute the expression.

Required CTE Fails Closed

If a source position requires semantic CTE and the compiler cannot produce the required compile-time value, it cannot silently:

• emit a runtime initializer call;
• insert a runtime generic dictionary;
• allocate the result dynamically at startup;
• replace a forbidden CTE effect with host execution;
• reinterpret an evaluator-local pointer as a runtime pointer.

Any future runtime-initialization mechanism must be explicitly defined by its own language rule.

CTE Feeds the Ordinary Compiler Pipeline

Conceptually:

CompilationPlan
    -> plan-time evaluation
    -> active source graph
    -> typed semantic analysis
        <-> semantic CTE as required
        <-> generic/type/layout/target semantic services
    -> verified Semantic IR
    -> Sec-MLIR / MLIR
    -> LLVM
    -> artifact

Semantic CTE operates on already resolved typed Sec semantics. It does not redo source-level name lookup, overload resolution, generic inference, member lookup or visibility resolution while executing.

The implementation may use an interpreter, dedicated evaluator IR, bytecode, JIT or reused MLIR infrastructure internally.

Those implementation choices must preserve canonical Sec semantics and the active compilation plan.

MLIR/LLVM constant folding remains optional optimization and is not a semantic fallback for required CTE.

Diagnostics

CTE diagnostics should say why compile-time evaluation was required and what actually failed.

Forbidden executed effect

compile-time evaluation of `BuildSize` requires filesystem access

the initializer must be established during compilation

call path:
    BufferSize
    -> BuildSize
    -> ReadConfigurationFile

filesystem I/O is not available during semantic compile-time evaluation

Path-sensitive forbidden operation

compile-time evaluation cannot execute `ReadFromRuntimeSource`

the call is reached for this concrete compile-time argument set

help: change the compile-time input so that a CTE-safe path is selected
help: remove the runtime-only operation from the executed compile-time path

Dependency cycle

compile-time dependency cycle

    A
    -> B
    -> A

neither required value can be established without the other

Resource limit

compile-time evaluation exceeded the call-depth budget

root expression:
    BuildLookupTable()

help: reduce recursive depth
help: restructure the computation
help: increase the permitted compiler CTE budget when appropriate

Value not materializable

compile-time evaluation succeeded, but the resulting value cannot be materialized

the result contains a view backed by transient evaluator storage

help: materialize an owning static value instead
help: return a value with a defined static representation

Semantic failure

compile-time evaluation failed: assertion failed

required by:
    static initializer `BufferSize`

call path:
    CalculateBufferSize
    -> ValidateConfiguration

A generic message such as not a constant expression is insufficient when the compiler knows the actual root cause.

The compiler should distinguish:

• not CTE-evaluable;
• CTE execution failed;
• resource limit reached;
• dependency cycle;
• successful value not materializable;
• compiler implementation gap;
• compiler invariant failure.

A language construct that is valid under canonical CTE rules must not be reported as invalid Sec merely because the current compiler has not implemented that evaluator operation yet.

LSP and Tooling

The compiler workspace is the source of truth for compile-time evaluation. The LSP does not implement an independent constant evaluator.

Tooling may expose:

• the established compile-time value;
• why the value is required at compile time;
• dependencies of the evaluation;
• call-chain provenance;
• generic concrete context;
• origin module for cross-module evaluation;
• the forbidden effect or semantic failure causing rejection;
• resource-budget exhaustion;
• whether evaluation succeeded but materialization failed.

Cancellation of obsolete editor work is not a source-language CTE failure and should not produce a stale program diagnostic.

Best Practices

• Write ordinary Sec functions; do not design a parallel “compile-time API” unless a real semantic distinction exists.
• Keep functions used by required CTE deterministic and free of ambient I/O/state dependencies.
• Use explicit arguments for values that influence compile-time computation.
• Do not depend on compiler-host pointer size, addresses, endianness or ABI.
• Remember that a runtime-only operation is allowed in a function when the concrete CTE path never executes it.
• Use ordinary ownership and borrowing rules even for temporary compile-time values.
• Do not assume transient evaluator allocation means a runtime allocator resource is available.
• Distinguish “can be evaluated at compile time” from “can be embedded as a static program value”.
• Keep required compile-time dependency graphs acyclic.
• Do not use CTE as a substitute for reflection or source generation.
• Do not assume CTE introduces arbitrary const/value generic parameters.
• Keep recursive or loop-heavy CTE bounded enough to compile predictably.
• Use @target/@when for plan-time source selection rather than trying to call ordinary CTE functions during plan formation.
• Use the canonical value.SizeOf and TypeName.SizeOf property forms.

Summary

• Sec 0.1 defines compile-time evaluation of ordinary typed Sec expressions.
• Semantic CTE uses ordinary Sec arithmetic, control flow, functions, Result/Option, ownership, borrowing, destruction and defer semantics.
• CTE does not introduce a second integer, ownership, lifetime or error model.
• Sec 0.1 has no const fn, comptime fn, compile-time block or IsCompileTime() source mechanism.
• An ordinary function may execute at runtime in one context and during semantic CTE in another.
• A function cannot observe merely that it is currently being evaluated at compile time.
• The compiler distinguishes plan-time-required and semantic-CTE-required contexts.
• Plan-time evaluation occurs before the active semantic source graph is complete.
• Plan-time evaluation is deliberately restricted.
• @target and @when use the plan-time model.
• Semantic CTE runs after enough typed semantic information is available.
• Semantic CTE may execute ordinary user-defined functions.
• No special compile-time function modifier is required.
• Required CTE is distinct from optional optimizer constant folding.
• An ordinary runtime expression remains a runtime expression even if the compiler can fold it.
• A value being statically known does not automatically make its source position a compile-time-required context.
• The rule owning a source construct determines whether CTE is required and which context class applies.
• Module/static initializers may be semantic CTE-required where their owning rules require compile-time establishment.
• A failed required static initializer does not silently become a runtime initializer.
• Mutable static storage is ordinary runtime mutable state after initialization.
• Successful CTE produces typed Sec values preserving nominal identity.
• CTE values are semantic values, not compiler-host byte blobs or host addresses.
• Cross-compilation uses target Sec semantics rather than host ABI semantics.
• Types are not ordinary first-class CTE values in Sec 0.1.
• CTE introduces no general Type/TypeInfo metatype.
• CTE does not automatically expose fields, methods, symbols or compiler IR as reflection data.
• Compiler knowledge does not automatically become source-visible reflection.
• CTE produces values and cannot generate or rewrite source declarations.
• CTE-generated strings are strings, not source text to be reparsed.
• Canonical SizeOf source forms are value.SizeOf and TypeName.SizeOf.
• SizeOf(TypeName) is not the canonical Sec 0.1 form.
• CTE does not introduce implicit generic introspection such as testing whether T == int.
• CTE does not automatically introduce arbitrary value/const generic parameters.
• CTE legality is path-sensitive to the operations actually executed for the concrete invocation.
• A runtime-only operation on an unexecuted branch does not invalidate another CTE path.
• Semantic CTE supports local mutation, control flow, loops, function calls, concrete generics, aggregates, Result, Option, try, assert, panic semantics, allocation, ownership, borrowing, destruction and defer.
• CTE cannot read or mutate ordinary mutable runtime static state.
• Filesystem, network, ambient environment, current time, ambient entropy, target memory, MMIO, volatile, atomics, barriers, concurrency and ordinary foreign calls are forbidden when executed during CTE.
• Explicit deterministic computation on compile-time values is allowed even when it implements a pseudo-random algorithm.
• Entering unsafe neither disables CTE nor grants extra CTE capabilities.
• Unsafe CTE still cannot access arbitrary host/target memory or arbitrary foreign code.
• Semantic CTE may allocate transient evaluator-local storage.
• Transient CTE allocation is not target runtime allocation.
• The compiler may not substitute evaluator storage for an explicit runtime allocator object.
• Ordinary ownership, move, copy and borrowing rules apply during CTE.
• Compile-time values are not automatically copyable.
• Ordinary deterministic destruction occurs for CTE-local values when source semantics reach it.
• Destructors executed during CTE must themselves use CTE-permitted semantics.
• Safe references may exist during CTE but evaluator-local identity cannot escape as runtime identity.
• Raw evaluator addresses cannot escape as program pointer/integer identity.
• Target address metadata is distinct from evaluator-local addresses.
• CTE must never dereference target hardware memory.
• Compile-time evaluability and static materializability are distinct properties.
• A value may evaluate successfully yet fail static materialization.
• Scalars, fixed aggregates, Option, Result and immutable strings may be materializable when their owning representation rules permit it.
• Dynamic owning collections may be useful transiently during CTE without having defined static materialization.
• Views/slices over evaluator-local storage cannot escape unless valid runtime/static backing identity is created separately.
• Static materialization recursively validates the complete reachable value graph.
• Arbitrary cyclic evaluator object graphs have no implicit static-heap semantics in Sec 0.1.
• A materialized program value receives a new program/storage identity; it is not the evaluator object.
• Required compile-time values form semantic dependency graphs.
• Dependency order, not textual declaration order, controls evaluation.
• Independent CTE requests may be reordered or parallelized without observable semantic difference.
• Compile-time value dependency cycles are errors.
• Recursive function execution is not automatically a compile-time dependency-cycle error.
• Recursion is allowed when the concrete evaluation terminates within resource limits.
• Dependency cycles may cross values, types and layout facts.
• Public functions may execute during semantic CTE across module boundaries.
• Cross-module CTE does not bypass source visibility.
• Origin-private helpers may execute only as already-resolved parts of a legal origin body; they do not become importable.
• Generic CTE uses the same canonical concrete specialization identity as runtime semantics.
• A program-level Result.Err(...) can be a successfully evaluated CTE value.
• Compiler CTE failure is separate from a source function's Result error channel.
• Reached assertion failure, panic or fatal checked semantic operation causes required CTE failure.
• Loops and recursion do not require a general static termination proof.
• CTE is protected by finite budgets such as execution steps, call depth, transient memory and aggregate value size.
• Resource exhaustion does not prove semantic non-termination.
• Wall-clock time is not canonical deterministic CTE semantics.
• CTE must be deterministic for equal semantic inputs and compilation plan.
• Ambient compiler-host filesystem, environment, time and entropy are not hidden inputs.
• Successful evaluation is followed by the owning construct's type/domain validation.
• A successfully evaluated but invalid array extent or enum value is an owning-construct error, not an evaluator failure.
• Required CTE fails closed and never silently falls back to runtime initialization or host execution.
• Semantic CTE operates on resolved typed semantics rather than repeating source name lookup or overload resolution.
• CTE feeds the ordinary Sec-MLIR → MLIR → LLVM → artifact pipeline; it does not replace it.
• MLIR/LLVM constant folding is optional optimization and not a fallback for required semantic CTE.
• Diagnostics should distinguish not-evaluable operations, semantic evaluation failure, resource limits, dependency cycles, materialization failure, implementation gaps and compiler invariant failures.
• LSP tooling consumes compiler CTE results and must not implement an independent Sec constant evaluator.