[swift-evolution] [Completing Generics] Private and multiple conformances

[Joe Groff]

> On Mar 2, 2016, at 8:26 PM, Douglas Gregor <dgregor at apple.com> wrote:
> 
> 
>> On Mar 2, 2016, at 5:38 PM, Joe Groff <jgroff at apple.com <mailto:jgroff at apple.com>> wrote:
>> 
>> 
>>> On Mar 2, 2016, at 5:22 PM, Douglas Gregor via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> Private conformances 
>>> 
>>> Right now, a protocol conformance can be no less visible than the minimum of the conforming type’s access and the protocol’s access. Therefore, a public type conforming to a public protocol must provide the conformance publicly. One could imagine removing that restriction, so that one could introduce a private conformance:
>>> 
>>> public protocol P { }
>>> public struct X { }
>>> extension X : internal P { … } // X conforms to P, but only within this module
>>> 
>>> The main problem with private conformances is the interaction with dynamic casting. If I have this code:
>>> 
>>> func foo(value: Any) {
>>>   if let x = value as? P { print(“P”) }
>>> }
>>> 
>>> foo(X())
>>> 
>>> Under what circumstances should it print “P”? If foo() is defined within the same module as the conformance of X to P? If the call is defined within the same module as the conformance of X to P? Never? Either of the first two answers requires significant complications in the dynamic casting infrastructure to take into account the module in which a particular dynamic cast occurred (the first option) or where an existential was formed (the second option), while the third answer breaks the link between the static and dynamic type systems—none of which is an acceptable result.
>> 
>> You don't need private conformances to introduce these coherence problems with dynamic casting. You only need two modules that independently extend a common type to conform to a common protocol. As Jordan discussed in his resilience manifesto, a publicly-subclassable base class that adopts a new protocol has the potential to create a conflicting conformance with external subclasses that may have already adopted that protocol.
> 
> Right, multiple conformances do happen in our current model. Personally, I think that the occurrence of multiple conformances should effectively be an error at runtime unless the conformances are effectively identical (same type witnesses with the same conformances may be a reasonable approximation), and even then it’s worthy of a diagnostic as early as we can produce one, because the amount of infrastructure one needs to handle multiple conformances is significant.

If it's a runtime error, that's a huge resilience liability, since any library adding a conformance would potentially be causing its users to start crashing at load time.

>> This seems to me like poor grounds for rejecting the ability to have private conformances. I think they're a really useful feature.
> 
> With what semantics? Truly embracing private and multiple conformances means embedding it in type identity:
> 
> // Module A
> public protocol P {
>   associatedtype A
> }
> public struct X<T : P> { }
> 
> // Module B
> struct Y { }
> 
> // Module C
> import A
> import B
> extension Y : private P {
>   typealias A = Int
> }
> 
> public func f() -> Any { return X<Y>() }
> 
> // Module D
> import A
> import B
> extension Y : private P {
>   typealias A = Double
> }
> 
> public func g(x: Any) {
>   if let y = x as? X<Y> { /* do we get here? */ }
> }
> 
> // Module E
> import A
> import B
> import C
> import D
> g(f())
> 
> It’s not that we can’t make this behave correctly—the answer is “no”, we don’t get into the “then” block, because modules D and E effectively have different types X<Y> due to the differing conformances—but that making this behave correctly has a nontrivial runtime cost (uniquing via protocol conformances) and can cause major confusion (wait, X<Y> isn’t a single thing?), for what I suspect is a fairly rare occurrence.

Yeah, I suspect the overlap of dynamic casting and use cases for private conformances is small, so it seems unfortunate to me to hobble the language around the needs of dynamic casts. A workable rule might be to say that private or internal conformances aren't exposed to runtime lookup, so are never found by as? casts. We could then statically reject the `as? X<Y>` cast here since the X<Y> instantiation depends on a runtime-invisible conformance.

-Joe

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