@availability on conformances

As the gargantuan Prepitch: Character integer literals - #299 by Ben_Cohen moves closer to review a hitch was found at the last minute that it will be defining new conformances to the protocol ExpressibleByUnicodeScalarLiteral and according to the tenants to ABI stability these need to have their @availablility gated so programs compiled using the new conformances are not deployed to a device which does not support them.

One solution would be to have @available take effect on extensions viz:

@available(swift 5.1)
extension Int8 : ExpressibleByUnicodeScalarLiteral {}

were the conformance would be marked as only available given the condition specified and this would also apply to any elements declared inside the extension block. This currently parses but has no effect. Does anybody have any other suggestions?

1 Like

Thanks for opening up a thread for this!

I think the trickier part is what to do at the point of use, rather than declaration, of the conformance. There's a lot more ground to cover than with function calls e.g. would you need to if #available passing an availability-constrained conforming type as an argument to a function? The availability consequences could also be really tough for the user to comprehend as it gets buried under other layers. For example a conditional conformance of a type to a protocol might depend on the availability of another conformance. The compiler diagnostics would need to be really solid to avoid maddening "why isn't this compiling!!!" issues.

1 Like