[swift-evolution] (Pitch) Conformance Regions

[Jeremy Pereira]

> On 30 Mar 2017, at 18:07, Ross O'Brien via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 


> It has become an idiom of Swift to declare an extension to a type for each protocol we want it to conform to, for reasons of code organisation and readability. This can be true even if conformance to the protocol was a primary intent of creating the type in the first place.

But this is only a convention. It’s not a compiler error to declare protocol conformance on the min type definition and it is not wrong to declare conformance on the main type definition.

> 

> Suppose we created a 'conformance region' inside a type declaration - a scope nested within the type declaration scope - and that this conformance region had its own access level. It's inside the type declaration, not separate from it like an extension, so we can declare properties inside it. But literally the only properties and functions declared inside the region but visible anywhere outside of it, would be properties and functions declared in the named protocol being conformed to.
> 
> So, visually it might look like this:
> 
> struct Foo
> {
>   conformance Bar // or conformance Foo : Bar, but since the region is inside Foo that's redundant
>   {
>     var integer : Int // visible because Foo : Bar, at Bar's access level
> 
>     var counter : Int = 0 // only visible inside the conformance scope, because not declared in Bar
> 
>     func increment() // visible because Foo : Bar, at Bar's access level
>     {
>       counter += 1
>     }
>   }
> }

Here is a problem with the above. Suppose you hadn’t helpfully annotated each of the vars with a comment telling us where it is visible, a reader couldn’t tell at a glance what the visibility of each var is without looking it up in the protocol.

> 

IMO this adds a lot of unnecessary complexity in order to offer language support for one particular way of laying out your code.