I think there are two main styles of declaring conformances. The inline style has the conformance declaration within the type declaration and is convenient for certain frameworks or even simple types:
struct MyView: View {
var body: some View { Text(“Hello World”) }
}
This example is pretty simple and given the SwiftUI it’s arguably hard to mess this up using autocompletion. But it can still be confusing to work through build errors if, for example, the return type is changed. As mentioned upthread, this is largely because the compiler can’t assume that ‘body’ is a witness and thus emits a conservative, often confusing, error. So, a simple autocompleted conformance keyword for witnesses would do the trick here.
The other extension-based conformance declarations are common for complex types with multiple properties and/or other protocol conformances. Usually, each extension implements one protocol (and the protocols it inherits from):
struct MyCollection<E> { … }
extension MyCollection: Equatable where E: Equatable { … }
extension MyCollection: Hashable where E: Hashable { … }
Adding conformance
to every witness is clearly excessive. One solution would be to only allow witnesses of the protocols that are conformed to within the current extension. But this approach makes it difficult and verbose to add helper methods. As previously suggested, helper methods often have lower visibility than the protocol and adding something like noconformance
for every helper would add unnecessary friction. A better solution might be to specify the access level of the protocol when declaring a conformance. Thus, the protocol’s access level will be clear and unnecessary access-level modifiers within the extension could be dropped. This practice is already enforced in some projects because it’s concise, so this feature would be built on top of an existing feature. Since the conformance has explicit visibility, any declaration with a lower access level will be clearly an implementation detail without requiring noconformance
. This way, existing code using this style will mostly work even after a potential migration, since these practices are already commonplace.
As for the name of the keyword, I support impl
. It’s already used in other languages and part of that is because it’s succinct. Inline conformance’s are used pervasively in many projects (including many SwiftUI projects), so having a short keyword be autocompleted in will be less intrusive.