[swift-evolution] [Pitch] Remove type inference for associated types
dabrahams at apple.com
Tue Jun 28 18:48:13 CDT 2016
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
>> Well, the type checker's inference engine has *always* been kinda
> Dave is dramatically understating the pain that this inference has
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
> 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
More information about the swift-evolution