Automatic Requirement Satisfaction in plain Swift

[Karl]

@Joe_Groff

I feel that compile-time evaluation will also be important to having a satisfying model for working with variadics, since it is natural to want to work with them as collections rather than use otherwise unidiomatic cons-walking techniques.

I'm not sure compile-time evaluation matters to constrained extensions (such as for protocol default implementations), unless you're talking about making compiler-evaluable code part of the type system.

I mean - it would be really cool...

extension FixedSizeArray<Element, let Size: Int> where Size.isMultiple(of: 2) {
  // Dreaming that we had generic value parameters...
}

But I'm doubtful that that kind of thing is actually feasible, though. I remember asking if it would be possible to use it in conditional compilation:

@owenv

IMO constant-evaluation-based conditional compilation is not easily supported by any traditional model. The current constant evaluation infrastructure runs as a mandatory SIL pass, which is unlikely to change, whereas conditional compilation has to occur before Sema to remain useful across different platforms. This makes any if directive body that can't be independently lowered to SIL problematic, including the existing support for conditionally compiled case blocks.

So if I understand that right, the compile-time evaluation happens after type-checking, meaning everything before that (parsing, type-checking itself including constrained extensions) can't make use of the results.