> On Feb 13, 2017, at 8:14 AM, Adrian Zubarev <adrian.zuba...@devandartist.com>
> 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. 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.
The idea is that a type in Module B could not conform to `SQLiteLoggable`
without also having a valid conformance to `SQLiteValue`—either by taking a
type Module A conforms to `SQLValue` and retroactively conforming it to
`SQLiteLoggable`, or by adding a conformance to `SQLiteConvertible` in Module
B. So this would not be allow you to work around `SQLiteValue`'s non-open-ness.
--
Brent Royal-Gordon
Architechies
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
