> On 30 Mar 2017, at 18:07, Ross O'Brien via swift-evolution
> <[email protected]> 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.
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
