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