[swift-evolution] [Pitch] consistent public access modifiers

Matthew Johnson matthew at anandabits.com
Mon Feb 13 10:27:21 CST 2017

> On Feb 13, 2017, at 10:14 AM, Adrian Zubarev via swift-evolution <swift-evolution at swift.org> wrote:
> Is that assumption correct?
> // Module A
> public protocol SQLiteValue {
>     init(statement: SQLiteStatement, columnAt index: Int) throws
>     func bind(to statement: SQLiteStatement, at index: Int) throws
> }
> // Module B
> protocol SQLiteLoggable : SQLiteValue {
>     var logDescription: String { get }
> }
> I could not follow your example there. If SQLiteLoggable is from module B than this should be an error in my opinion.
Yes, Brent was using `public protocol` with the same semantics that `public class` has today (i.e. not open) so this would be an error.

> Otherwise open would have less meaning on protocols, because you always could create an empty protocol that has a super public protocol which you’re not allowed to conform to in module B. This would be a silly workaround to being able to conform to it SQLiteValue indirectly without any further requirement like in SQLiteValueConvertible.
> That said, it makes no sense to me to allow that, because it’s simply a workaround to conform to a protocol which public-but-not-open tries to prevent.
> // Module X
> public protocol A {}
> open protocol AA : A { func foo() } // Fine
> // Module Y
> struct B : A {} // Error
> struct B : AA { func foo() { .. } } // Okay
No, `struct B : AA` is an error because in order to conform to `AA`, `B` must also conform to `A`, which it cannot because `A` is closed.

> protocol C : A {} // Error because `struct B : C` would equal `struct B : A`
No, this is allowed.  However the only types that can conform to `C` are types declared in module X that *already* conform to `A`.  They may be extended to retroactively conform to `C`.

> protocol CC : AA {} // Should work even empty, because we have more requirement from `AA`
> public should have a consistent meaning across all types from module A in module B, which is ‘not allowed to sub-type from’ and in case of protocols additionally ‘not allowed to conform to’.
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170213/3d74f36d/attachment.html>

More information about the swift-evolution mailing list