> On Feb 13, 2017, at 10:14 AM, Adrian Zubarev via swift-evolution
> <[email protected]> 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
> [email protected] <mailto:[email protected]>
> https://lists.swift.org/mailman/listinfo/swift-evolution
> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
