[swift-evolution] [Pitch] Remove type inference for associated types

[Dave Abrahams]

on Tue Jun 28 2016, Douglas Gregor <dgregor-AT-apple.com> wrote:

>> On Jun 27, 2016, at 12:56 PM, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> 
>> on Sat Jun 25 2016, Austin Zheng <swift-evolution at swift.org> wrote:
>> 
>
>>>> On Jun 25, 2016, at 6:23 AM, Matthew Johnson <matthew at anandabits.com> wrote:
>>>> 
>>>> Hi Austin,
>>>> 
>>>> I’m sorry to say, but this proposal makes me really sad.  I consider
>>>> associated type inference one of the more elegant aspects of Swift.
>>>> It would be very unfortunate to lose it.
>>> 
>>> There are lots of "elegant" things that Swift could do, but has chosen
>>> not to do for pragmatic reasons (e.g. generalized implicit
>>> conversions, type inference that crosses statement boundaries). Given
>>> how terrible the development experience can be right now in the worst
>>> case, I would happily trade off some measure of convenience for better
>>> tooling.
>> 
>> Well, the type checker's inference engine has *always* been kinda
>> unreliable,
>
> Dave is dramatically understating the pain that this inference has
> caused. 

What are you talking about? I did not characterize the magnitude of the
pain in any way whatsoever.

> Because this is the only place we do global type inference, it’s put
> tremendous pressure on the type checker that caused a huge number of
> bugs, crashes, and outright incomprehensible behavior. I reimplemented
> the inference of associated type witnesses in April of 2015
> (https://github.com/apple/swift/commit/126e404fe5bf0be81206f22c83a61f6689d18854
> <https://github.com/apple/swift/commit/126e404fe5bf0be81206f22c83a61f6689d18854>,
> for reference), when the existing implementation unbearable. It got
> *far* better, but it’s still not global *enough* to actually be
> predictable, and the legacy of this mis-feature manifests in a number
> of weird ways (e.g., typealiases in protocol extensions cannot be used
> to satisfy associated type requirements, weird rules for when a
> defaulted associated type gets used).
>
>> and the experience is made much worse by the lack of
>> recursive protocol requirements and the inability to express other
>> constraints that would better guide inference, and by the “underscored
>> protocols” such as _Indexable that are required to work around those
>> limitations.  IMO it's premature to remove this feature before the
>> inference engine is made sane, the generics features are added, and the
>> library is correspondingly cleaned up, because we don't really know what
>> the user experience would be.
>
> Well, there’s a chicken-and-egg problem. The complexity of this
> inference is getting in the way of other improvements. 

I figured that might be the case.  If we have to drop that inference in
order to evolve the other improvements in a sane way, I strongly endorse
doing so, at least temporarily :-) But I think we should be prepared to
re-evaluate the situation after the dust settles.

> For example, inference of associated types for conditional
> conformances requires that associated type witness deduction consider
> additional requirements, which is a complexity we would entirely avoid
>
>> Finally, I am very concerned that there are protocols such as Collection,
>> with many inferrable associated types, and that conforming to these
>> protocols could become *much* uglier.
>
> That’s the general concern I have as well: how much boilerplate does
> this add? In many cases, we get some of the associated type witnesses
> for Collection types for free, and I don’t know to what extent we can
> emulate that with defaulted associated type requirements and
> typealiases in protocol extensions.
>
> That said, I’ll take some minor regressions in this area for the
> massive simplification that this proposal brings.

It remains to be seen how minor the usability regressions are, of
course.

-- 
Dave