Another issue here (perhaps) is, what if you misspelled the associated type
when you attempted to typealias it manually? Would it not just make a new
typealias with your misspelled name and then, potentially, you’d get an error
or would something end up working but in unexpected ways? Would the typo be
easy to identify if you had a lot of typealiases or associatedtypes or typos?
protocol P {
associatedtype Index = Int
}
struct X : P {
typealias index = String // whoops - no capital I - how long does
this bug take to find? :P
}
There will always be bugs, of course. Maybe this isn’t a significant concern?
l8r
Sean
> On Jun 29, 2016, at 8:55 AM, Brandon Knope via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> 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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
