Hi everyone. The review of SE-0360, Opaque result types with limited availability, has concluded, and the Language Workgroup has decided to accept this proposal as is. Much of the review discussion centered on how the functionality could be generalized in the future:
- As currently proposed and implemented, the feature only allows the underlying type of an opaque type to vary in response to certain configurations of
if #availablestatements. In principle, this could be generalized to arbitrary static control flow involving availability checks, whether they beif,guard, orswitch, or#availableor#unavailable. The current implementation makes this generalization not straightforward. The Language Workgroup agrees that the generalization is desirable, but we don't want to require the generalization to happen to allow the basic implementation to be accepted. By the implementability requirement for reviewing proposals, we can generalize the functionality in follow-up proposals as the implementation improves. - The question was also raised whether other declarations, such as local stored properties, should also allow for varying underlying types in addition to functions. This is another case where generalizing the implementation is not straightforward, and the functionality could be implemented by other means (such as moving the initializer into a local function that produces the opaque initial value of the variable), so we leave that generalization to a future proposal when an implementation is provided.
- The underlying principle that allows opaque types to change in response to
#availableconditions is more general: an opaque underlying type is required to be constant for the duration of a process's execution, but nothing fundamentally requires the underlying type to be the same in different executions of the process. This is what already allows, for example, an executable to link against a newer version of a dynamic library that implements an opaque type interface returning a different underlying type from the older library. By that principle, opaque types could also be allowed to change in response to static conditions involving other process constants, such as globalletbindings, or constant-evaluable expressions. We believe that availability is still a useful enough subset to motivate this proposal, since it's key to allowing evolution of stable APIs while maintaining compatible behavior with older OS versions, so we leave generalization to other conditions to a future proposal.
Thank you to everyone who participated in the review!