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

[Matthew Johnson]

> On Jun 28, 2016, at 1:25 PM, Douglas Gregor via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On Jun 27, 2016, at 12:56 PM, Dave Abrahams via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> 
>> on Sat Jun 25 2016, Austin Zheng <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>>>> On Jun 25, 2016, at 6:23 AM, Matthew Johnson <matthew at anandabits.com <mailto: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. 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. 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.

Do you have any comments on Dmitri’s suggested alternative?  I would like to see that discussed before any proposals are reviewed.  That discussion is likely to influence my opinion quite a bit.

> 
> 	- Doug
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160628/352e0ab6/attachment.html>