> A return type makes a lot of sense linguistically but does not cover all > practical cases because you might not be the one deciding what the function's > signature is. For example, you might implement a protocol method that is > non-optional, but you never expect to be called. The only way to indicate > that to the compiler is with an attribute.
If Swift permits return type covariance—that is, for an override or implementation to tighten the return type—then this will happen naturally: Never is a subtype of all types, so you can validly change any return type to Never and meet the supertype's requirements. I believe Swift supports return type covariance for overridden methods, but not for protocol requirements. This is, in my opinion, an incorrect behavior which should be changed. -- Brent Royal-Gordon Architechies _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
