> On Jun 6, 2016, at 6:51 PM, Douglas Gregor <[email protected]> wrote: > >> >> On Jun 5, 2016, at 3:24 AM, L. Mihalkovic via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >> The issue is to decide on the applicability scope. Thinking 'my app/their >> stuff' is an illusion. To the compiler & runtime there is only code split >> into modules, some in source code and others as dylibs (.dll, .so, ...). Any >> extension based conditional refines a protocol everywhere. What's hard is to >> compute the complete effects of these changes predictably, reliably and >> fast. Because when we consider 'but look, i have a single small extension', >> the compiler&runtime must be ready to deal symetrically with anything we >> throw at it. They can't start building 15 different ways the compute the >> side effects based on many different scenarios because it will be un-ruly >> code, and too complex to try to explain to us what we will see. >> The circular redefinitions case is one of the knightmares that hides in >> there... would mean having to assign priority to scopes, when there is no >> scopes yet. At the moment, the binary conformance table contains records for >> 3 types of conformances. First step would be to add a new type to match >> extension based conformance, and then record where it came from, and add >> some priority scheme to be able to navigate any conformance chain(remember >> that the pb grows everytime we decide 'oh cool, lets use a Padleft module >> rather than write my own 15 lines to do it - see the recent pb with nodejs). >> Not a simple task even with time, which they do not have now. >> >> @core_team i know this is a coarse explanation, but hopefully at least in >> the right ballpark. > > Roughly, yes. The specific problem regards answering the question “where must > the runtime look to determine whether a given type X conforms to protocol > P?”. Right now, the runtime conceptually needs to look: > > 1) Into a list of known protocol conformances for the type X, and > 2) If X is a class type, the list of known protocol conformances for > the superclass of X (recursively) > > If we add the ability for a protocol extension to add a conformance to > another protocol, add to that:
I was under the impression that extension defined conformance would fit neither NormalProtocolConformance (nominal) nor SpecializedProtocolConformance (generic) and that a StrawmanExtensionProtocolConformance would then be required. > > 3) Into the list of protocol extensions of other protocols Q that > provide conformance to P > > That’s a fairly significant expansion, and for each of the protocol > extensions in (3), we need to evaluate whether X conforms to the extended > protocol Q (and any additional constraints placed on that protocol extension). because of the potential for contradictory definitions or redefinitions, I was under the impression that it might be useful to define some sort of prioritization for deciding which should be applied first. But that’s probably because I don’t understand the topic as much as you do. That is also why I was thinking that aside from priority, the structures might also have to be tagged with something to tell where they come from (maybe priority is just how these scope source are read). I guess this is also a requirement that would stem from supporting private/local conformance. > - Doug > > >> >> On Jun 5, 2016, at 9:49 AM, Thorsten Seitz via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >>> >>>> Am 04.06.2016 um 23:18 schrieb Austin Zheng via swift-evolution >>>> <[email protected] <mailto:[email protected]>>: >>>> >>>> Hello Dan, >>>> >>>> You'll be pleased to learn that conforming generic types conditionally to >>>> protocols is on the roadmap (and is one of the highest priority items for >>>> the versions of Swift following 3.0): >>>> https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#conditional-conformances- >>>> >>>> <https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#conditional-conformances-> >>>> >>>> However, it's unlikely that protocols will gain conditional conformance: >>>> https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#conditional-conformances-via-protocol-extensions >>>> >>>> <https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#conditional-conformances-via-protocol-extensions> >>> "However, similar to private conformances, it puts a major burden on the >>> dynamic-casting runtime to chase down arbitrarily long and potentially >>> cyclic chains of conformances, which makes efficient implementation nearly >>> impossible.“ >>> >>> I’ve been wondering what the problem with the implementation is. I mean >>> instead of using an extension the same conformance could have been declared >>> beforehand, i.e. instead of >>> >>> protocol P { func foo() } >>> protocol Q { func bar() } >>> extension Q : P { func foo() { bar() } } >>> >>> we could have written the allowed >>> >>> protocol P { func foo() } >>> protocol Q : P { func foo() { bar() } } >>> >>> with the exact same effect. >>> >>> The only difference would be that the extension might have been in another >>> module than Q. >>> Is having to cross module boundaries causing the cited problems? Would the >>> same problems exist if in the second example Q would be defined in another >>> module? >>> >>> -Thorsten >>> >>> >>>> >>>> That document originates from a mailing list post made some time ago, and >>>> is a decent overview as to what sorts of type system features the Swift >>>> core developers are interested in building. >>>> >>>> Best, >>>> Austin >>>> >>>>> On Jun 4, 2016, at 2:12 PM, Dan Zimmerman via swift-evolution >>>>> <[email protected] <mailto:[email protected]>> wrote: >>>>> >>>>> Hey, >>>>> >>>>> I was interested in adopting the ability for a type that's generic in >>>>> some sense (either via generics or via associated types, in the case of >>>>> protocols) to conform to other protocols conditionally based on its type >>>>> parameter/associated type. For example: >>>>> >>>>> ``` >>>>> extension CollectionType: Equatable where Generator.Element: Equatable {} >>>>> >>>>> func ==<Collection: CollectionType where Collection.Generator.Element: >>>>> Equatable>(left: Collection, right: Collection) -> Bool { >>>>> return zip(left, right).reduce(true) { accumulator, tuple in accumulator >>>>> && (tuple.0 == tuple.1) } >>>>> } >>>>> ``` >>>>> >>>>> If this has already been proposed and knocked out/accepted please direct >>>>> me to the right place. >>>>> _______________________________________________ >>>>> 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] <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] <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] <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
