Does the current proposal imply that @const in a contravariant position requires that the value was produced by compile time logic but in a covariant position only indicates that the value is pure?
What is the distinction in the type signature between a function that is pure and can be called either at compiler or run time and a closure which was constructed at build time and has only compile-time captured context?
Should @pure and @const be distinct?
Related to literals, something I'm looking for is having recursive structures that only need to be written out statically and so effectively are always constructed as a literal.
Is there any consideration from having const as a qualification on a by-value type declaration like enum, requiring any value of that type to be constructed at compile time?
For example:
const enum Path {
case empty
case element(head: StaticString, tail: Path)
}
let path = Path.element(
head: "Foo",
tail: .element(
head: "bar",
tail: .empty
)
)
This could potentially mean that StaticString and BigIntLiteral can be described in such terms too:
const struct StaticString {
let utf8bytes: StaticArray<UInt8>
}
const struct BigIntLiteral {
let sign: Bool
let words: StaticArray<UInt>
}
This might potentially also mean that those types can be constructed from logic in a const function but that would require that function only ever be evaluated at build time (as opposed to simply being pure).
(I think in the above cases literal might better describe the desired effect rather than const)