Hello Swift community,
The review brought up a number of concerns about the proposal, but the overarching theme is that it isn't clear how this proposal fits into the overall picture for build-time constant evaluation in Swift, and with that it does not stand well on its own. This manifests in a few different ways:
Concerns about the virality of
@const: Noted in several places (e.g., here, here, and here), the concern here is that
@constwill end up being propagated throughout large swaths of Swift code, possible unnecessarily. Experience with related features of other languages (e..g, C++
constexpr) has shown this to be a problem. While this concern is more directed at the expected future direction of allowing functions to produce constant values than at this specific proposal, it is enough of a problem in other languages that it should be discussed and addressed.
Concerns that this proposal is too small a step toward constant evaluation: A number of responses argue that this proposal is too small to accept in isolation (e.g., here, here, here, and here), because by itself it provides only the guarantee that the argument, initializer, or witness uses a restricted form of expressions (based on literals) and types. This information isn't usable directly within the language or available tools without also having one of the future directions implemented.
@constproperties are guaranteed to be emitted as constant objects in the binary: There are a number of ABI issues that prevent constant initialization for semantically-constant values such as dictionaries (due to random seeding and existing ABI limitations) and instances of generic classes (due to type metadata instantiation). Constant initialization is complicated enough that it should be separated from this proposal.
The language workgroup notes that larger features often proceed through a series of incremental proposals, allowing each individual aspect to be considered in isolation. Concurrency, recent generics improvements, and regular expressions are recent examples of this approach. However, in such cases there is typically a roadmap document that describes the overall direction, making it easier to understand how a given proposal fits into the overall picture. Without such a roadmap, the effects of this particular proposal are hard to reason about. The language workgroup will work with the authors to develop a roadmap for constant evaluation in Swift. This proposal can then be positioned relative to that roadmap and reviewed in that context, which should address many of the concerns brought up in the review.