[swift-evolution] [swift-evolution-announce] [Review] SE-0108: Remove associated type inference

[Douglas Gregor]

> On Jun 29, 2016, at 4:38 PM, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> 	https://github.com/apple/swift-evolution/blob/master/proposals/0108-remove-assoctype-inference.md
> 
>> 	* What is your evaluation of the proposal?
> 
> I don't think the time is right.
> 
> I've been reading the code for Sequence, Collection, and the various protocols that they use (I actually went to bed with an almost finished email for the discussion thread), and I think this is going to be a big problem there. From what I can see, there are two places where they lean heavily on inference for basic usability:
> 
> 1. `Sequence.SubSequence` has no default type, but it is inferred to be `AnySequence<Iterator.Element>` in the absence of an alternative, because the standard library provides an extension full of `AnySequence<Iterator.Element>`-returning implementations. Honestly, I'm not sure why it doesn't have a default—some very basic testing in the REPL didn't seem to show any circularity problems—so my guess is that this one could be resolved.
> 
> 2. `Collection._Element` (actually `IndexableBase._Element`) is a *hidden* associated type which uses inference to break a nasty loop between `Collection` and `IndexingIterator`. (`IndexingIterator` wants to use the `Iterator.Element` of the collection it's used with, but if that `Iterator` is itself `IndexingIterator`, that would be a circular definition. Instead, it uses the collection's `_Element`, which is inferred to be the return type of the index subscript.) Without inference, we would have two options here, neither of them great:
> 
> 	a. Make `Collection.Element` a publicly visible associated type. Because we don't have `where` clauses for associated types yet, that would make it very easy to create a Collection whose `Element` and `Iterator.Element` did not match. (If we *do* make it a non-hidden associated type, I would suggest we add same-named generic parameters as another way to implicitly fulfill an associated type requirement; that would handle many collections automatically.)
> 
> 	b. Make the element type a second generic parameter to `IndexingIterator`. This would effectively prevent us from offering a default `Iterator` on `Collection`s.
> 
> Additionally, I believe the other un-defaulted associated types we'd like to infer if we can—`Collection.Index`, `Sequence.Iterator`, and `IteratorProtocol.Element`—could all be handled by simple "caveman inference" heuristics, rather than a full type inference pass. All three of these are used in either the types of un-defaulted properties (which cannot ever be overloaded) or the return types of un-defaulted nullary methods (which can be overloaded but rarely are). If we could use only those limited cases to guess the appropriate types, then plug them in and see if they typecheck, that would go a long way towards softening the blow of removing associated type inference.
> 
> So, in summary:
> 
> • I think that removing associated type inference will seriously impair Collection's usability and type-safety.

The usability argument I understand. It’s a big, open question. I hacked up a flag for swiftc (-Xfrontend -disable-associated-type-witness-inference) on this branch:

	https://github.com/apple/swift/tree/disable-associated-type-witness-inference

that simply disables associated type witness inference so we can experiment. If we do nothing to the standard library, the experience is awful for (e.g.) the case of a type that minimally conforms to today’s Collection. But we knew the standard library would need changes, because it heavily depends on this inference today, so we won’t have a good sense of what we can accomplish until someone actually tries to work with the proposed restriction. I, personally, don’t have the time to invest in this right now :(

> • I think that these issues ought to be mitigated in the future by new compiler features which we may not have the time to implement before we ship Swift 3.

You're talking about recursive protocol constraints (which would help collapse some of the underscored protocols) and where clauses on associated types in particular?

	- Doug