Compile-Time Constant Expressions for Swift

[anandabits (Matthew Johnson)]

@Joe_Groff

I think the discussion about non-type generic parameters in the proposal is a bit of a red herring. Constant evaluation is likely to be neither necessary nor sufficient to support this. Because of Swift’s generics model, we can support dynamic non-type generic parameters, so . Making type equality judgments might be able to use constant evaluation in some situations, but it’s likely we’ll want to support more flexible bidirectional deduction of at least some things, like integers. I think it’s largely an independent feature.

I was thinking specifically about using compiler evaluable expressions as arguments to non-type generic parameters and using those values in subsequent compiler evaluable expressions in the generic context. It isn't clear to me after reading the document whether that is something that would eventually be supportable or not, especially if the type of the non-type generic parameter was itself generic, such as: struct FixedArray<Size: UnsignedInteger, size: Size> {}.

I was also thinking about limitations on compiler evaluable expressions in generic contexts more generally after reading the section Intentional limitation: Constant expressions of generic type. It seems likely to me that generic code is the context where I would most frequently to want to take advantage of compile time evaluation. I hope there is a way to make the interpreter and the generic system work well together (in the fullness of time of course).