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

[Adrian Zubarev]

Okay thanks, that makes now sense to me. So even if we refine public protocols from module A with a custom protocol in module B, there is no way we can conform any other type from module B to it, but we could conform existing types of module A to our refined protocols.

That’s fine by me, because the consistent restriction of public would remain the same. :)



-- 
Adrian Zubarev
Sent with Airmail

Am 13. Februar 2017 um 17:27:36, Matthew Johnson (matthew at anandabits.com) schrieb:


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
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/b2f448f0/attachment.html>