SE-0359: Build-Time Constant Values

[ksluder (Kyle Sluder)]

I have an aesthetic concern.

Using a keyword or an introducer instead of an attribute

@const being an attribute, as opposed to a keyword or a new introducer (such as const instead of let ), is an approach that is more amenable to applying to a greater variety of constructs in the futures, in addition to property and parameter declarations, such as @const func . In addition, as described in comparison to Implicitly-Unwrapped Optionals above, this attribute does not fundamentally change the behavior of the declaration, rather it restricts its handling by the compiler, similar to @objc .

As others have pointed out, this proposal explicitly does not propose any mitigation for the virality of @const that is evidenced in other languages, particularly C++. As such, we can reasonably expect @const to start appearing very frequently. I believe this tips the scales to eliminating the @ prefix whenever possible.

The @objc analogy is a false equivalence, because most uses of @objc are inferred, and this proposal avoids the topic of const inference.

To make another analogy, Swift concurrency has both : Sendable and @Sendable. These could have been collapsed into a single @Sendable attribute, but I suspect the language designers would have found it aesthetically unpleasing to have @Sendable struct Foo { }.