What's the rationale for having associatedtype in protocols and typealias in the conforming types?
This has actually been a point of confusion for me as it seems inconsistent Brandon Sent from my iPad > On Jun 29, 2016, at 1:33 AM, Douglas Gregor via swift-evolution > <swift-evolution@swift.org> wrote: > > >> On Jun 24, 2016, at 10:50 PM, Austin Zheng via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> Hello all, >> >> Per Chris Lattner's list of open Swift 3 design topics >> (http://article.gmane.org/gmane.comp.lang.swift.evolution/21369), I've put >> together a proposal for removing type inference for associated types. >> >> It can be found here: >> https://github.com/austinzheng/swift-evolution/blob/az-assoctypeinf/proposals/XXXX-remove-assoctype-inference.md >> >> Thoughts, criticism, and feedback welcome. There are at least two slightly >> different designs in the proposal, and I'm sure people will have ideas for >> even more. > > Thanks for working on this. I have a couple of comments. > > I don’t think we should be adding the ability to write ‘associatedtype’ > declarations in classes/structs/enums. We already have the ability to > explicitly state the associated type witness by declaring a typealias, > struct, enum, or class with the appropriate name. Indeed, I feel like a lot > of complexity of the proposal is linked to adding ‘associatedtype’ > declarations into the language, and I’d rather this proposal stay narrow. > > I think it’s important for this proposal to show the other ways in which one > can get associated type witnesses without writing them explicitly in the > conforming type, even once inference goes away. For example, we have > associated type defaults, e.g., > > protocol P { > associatedtype Associated = Int > } > > struct X : P { > // Associated becomes Int if not otherwise specified > } > > and with typealiases in protocol extensions becoming real and useful, one > could also use protocol extensions: > > protocol P2 { > associatedtype Index > } > > extension P2 { > typealias Index = Int > } > > which, of course, implies that one can use various tricks with constrained > protocol extensions and such. There isn’t any proposed change here, but it > illustrates that Swift programmers aren’t without recourse if type inference > for associated types go away. > > One concern with applying the above tricks is that existing code can change > meaning when inference goes away. For example, let’s think about the > “Iterator” type of a Sequence. It already uses default associated type > witnesses (not associated type witness inference!) to give a default of > IndexingIterator<Self>, e.g., > > protocol Sequence { > associatedtype Iterator: IteratorType > func makeIterator() -> Iterator > } > > protocol Collection : Sequence { > associatedtype Iterator = IndexingIterator<Self> > func makeIterator() -> Iterator // redeclaration helps inference > } > > When a type that conforms to Collection doesn’t provide makeIterator, it gets > a default one via: > > extension Collection where Iterator == IndexingIterator<Self> { > public func makeIterator() -> IndexingIterator<Self> { … } > } > > That will still work (yay). However, simply removing associated type > inference means that a collection type that *does* provide makeIterator()—but > not, directly, Iterator—would change behavior: > > struct IntCollection : Collection { > typealias Element = Int > func makeIterator() -> IntCollectionIterator { … } > } > > With associated type inference, we infer Iterator = IntCollectionIterator and > select IntCollection.makeIterator() to satisfy the makeIterator() requirement. > > Without associated type inference, we use the default Iterator = > IndexingIterator<Self> and select the makeIterator() from the protocol > extension (because IntCollection.makeIterator() now returns the wrong type), > which turns an error of omission into an unpleasant surprise. We might need > something like near-miss checking for defaulted protocol requirements (which > we discussed in the thread at > http://thread.gmane.org/gmane.comp.lang.swift.devel/1799) to help find those > surprises. They already exist today, of course, but removing associated type > inference would make them worse. > > Finally, one of the chief concerns is that we won’t be able to provide a nice > experience when conforming to the standard library’s collection protocols. I > would *love* to see some more thought to into how we can use the above tools > to handle it, although I suspect the only way to do that is to implement some > part of this proposal experimentally and see what it takes to get the > standard library and it’s tests working again. How far can the tools above go > toward reducing the need to specify various associated type witnesses in > conforming types? What are the surprises? > > - Doug > > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
