Sent from my iPhone
> On Sep 29, 2016, at 7:45 PM, Jonathan Hull <[email protected]> wrote: > > +1 to conditional conformances in general. >> >> What other designs were considered and rejected? It seems like some kind >> >> of escape hatch would be preferred if you happen to get into this >> >> situation, though you make some really good points about the pitfalls. >> > >> > I don’t have a fully-baked alternative proposal—it would probably have to >> > involve some kind of preference rule for picking the “best” set of >> > (consistent!) conformances to satisfy a particular request, introduce a >> > disambiguation syntax for cases where that preference rule does the wrong >> > thing, and some way of teaching the dynamic-casting machinery to do the >> > same thing. >> >> Yeah your description is already sounding like a lot of work :) > I still think it is worth looking at this issue in general though. I think it > is one of the big holes in swift’s grammar, and the sooner we find a way to > express distributed ordering, the less churn it will cause when we make the > change (and the more consistency we can have across language features which > share this issue). It doesn’t necessarily have to be fixed in this proposal > though, as long as we don’t paint ourselves into a corner. I agree that we need to address the inability to disambiguate in the language. I'd like to see it addressed comprehensively, so we don't end up with one syntax in part of the language that doesn't work in another, similar part of the language. So it should cover "I want to call this specific thing in this protocol extension defined in this other module..." and "I want to this method to implement that requirement of this specific protocol" and such. In a sense, this particular proposal doesn't "need" disambiguation because it bans ambiguities. > >> You get a compile error if there are two conformances of SomeWrapper to >> Equatable; it doesn’t actually matter whether they are conditional, but >> people are far more likely to expect to be able to having overlapping >> conditional conformances. >> >> Slightly off-topic but I was hit quick badly by this recently because two >> libraries I was trying to import both conformed UIControlState to Hashable >> to be able to use it as Dictionary indices. It seems like something that >> might happen kind of regularly with important protocols like Hashable and >> Equatable. > > I agree with David that the non-overlapping issue is going to come up a lot > around things like Equatable. Yeah, it's likely to happen most with libraries imported from C/Objective-C and the standard library's protocols, because the C/Objective-C types won't have considered those conformances initially and yet everyone uses the standard library protocols. > > One potential solution would be to have the ability to mark a conditionally > conforming extension as “weak” (or another term which has been bikeshedded). > In this case, it would then act similarly to default implementations of > protocols. That is, it would provide conformance if no one else was, but > defer to any other implementation which is available. This means library > authors can provide basic conditional conformance without locking out more > specific implementations. This deferral would likely be on a method by > method basis (similar to default protocol implementations), though the “weak” > (or equivalent) annotation would apply to the extension as a whole. This is roughly the shape of solutions we've discussed. There is some runtime validation we might need---for example, to make sure all of the conformances define the same associated type witnesses---but it's something we can probably do via lazy deduplication at runtime. - Doug > > Thanks, > Jon >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
