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

[Matthew Johnson]

> 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>