currently there appears to be a discrepancy in the treatment of methods that take an explicit parameter of uninhabited type, and those that have an uninhabited self param. the former is diagnosed as unreachable, and produces warnings for user code indicating it will never run, while the latter does not. additionally, the latter case still emits SIL for a method body that is (i assume) unreachable.
it seems to me that these cases should be handled analogously, but i'm curious if there are any reasons that would not be a reasonable change make.
There is a legitimate use case for instance properties/methods of uninhabited types. For example, in SwiftUI, Never conforms to the View protocol. Then, views which define their content using something oher than their body property (like views conforming to UIViewRepresentable) define their Body associated type as Never. That requires defining a body property, but it will never be called.
Maybe Swift could implicitly declare any protocol requirements on an uninhabited type that have a Self requirement (while skipping static requirements that don’t have a Self parameter since they’re still reachable), or it could suppress the “unreachable code” warning on these members.
yes, protocol conformance seems like a clear example where uninhabited types need to have whatever instance methods/properties are specified in the requirements. though it seems conceivable that those implementations could perhaps be elided in user code and synthesized in some manner by the compiler.
at any rate, in the case that you have members of uninhabited types, it would seem that there's no reason to emit code for the implementation (unless it's just a runtime trap or something), as it should not be executable.
thanks for the feedback – i hope to take a stab at addressing this discrepancy relatively soon.
The members have to exist to satisfy the protocol, and we should not synthesize them automatically. But the bodies of any instance methods are inherently unreachable and should be treated as such if they aren't left empty.
to digress slightly – why would something like this be a Bad Idea? for example:
// today, various conformances can be synthesized
struct S { var p: Int? }
extension S: Equatable {} // don't need to write out `==`
protocol P { var prop: Int? { get } }
extension Never: P {} // why could a stub conformance implementation not be synthesized?