Normal protocols can currently impose requirements on conforming types that they provide initialisers (such as Decodable and the various ā¦Representable and ā¦Convertible types).
It can also require that conforming types provide static vars that produce an instance of self with certain properties, such as floating pointsā .greatestFiniteMagnitude
or .zero
etc.
Whether or not this feature of protocols is useful to all, or not, is beyond the point. It is already possible today, and types use these features.
It is also the case that at call sites, there is no syntactic or semantic difference between an enum case and static var/func. You cannot tell without inspecting types, wether the following parameter is an enum, an option set or just a default instance of some complex type:
let result = someCalculation(roundingTowards: .zero)
Here, .zero
can be a number, a case of RoundingRule
, a single-element of RoundingOptions
, or maybe even a common shared instance of some much more complex type.
Point is; at call site, a case and a static var are identical. Combined with the fact that protocols can meaningfully express requirements on types that allow for such uses.
But you cannot today, write generic code over types that are for all intents and purposes semantically identical.
You can sometimes force an enum to conform, by providing a case alias through a static var indirection, but for already conforming types, you canāt simply express retroactive conformance. In fact, it is impossible to make it conform without renaming cases. The latter may not always be desirable when the type is mapping some external network response or whatever.