Skip to content

Requirements for const evaluation #24

Open
@lcnr

Description

@lcnr

What is this

This is a design document for const generics. Any discussions about its content should be on zulip. The conclusions of these discussions should then be edited back into this issue. Please do not post any comments directly in this issue.

Content

For generic constants in the type system to be sound, const evaluation must
not be able to differentiate between values considered equal by the type system.
Const evaluation must also be fully deterministic and must not depend on any external state
when used in the type system.

Floats

Using floats during CTFE is fully determinstic. So using
them inside of the type system is fine. CTFE can however
produce different results than what would happen on real hardware,
but this is not a concern for const generics.

Dealing with references and allocations

Other sources of non-determinism are allocations. This non-determinism
must however not be observed during const-evaluation (TODO: link to const-eval).

Any references used in a constant are considered equal if their targets are equal, which is also determistic. This is needed by valtrees. The specific design of valtrees also adds some other additional constraints to const evaluation which are listed on its page.

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-generic-exprsGeneric const expressionsC-design-docsCategory: This is part of our design documentationK-behaviorDocument Kind: regarding user visible behaviorP-necessaryPriority: will be needed at some pointS-active

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions