> On Jun 29, 2016, at 10:55 PM, Douglas Gregor <[email protected]> wrote: > > You're talking about recursive protocol constraints (which would help > collapse some of the underscored protocols) and where clauses on associated > types in particular?
I'm also talking about "caveman inference" if that's judged to be a good idea for usability, and anything else we need to make associated types ergonomic despite the loss of inference. (One underdeveloped thought I just had: keep the inference engine around and use it to suggest fix-its for unspecified associated types.) Ultimately what I'm saying is this: Removing associated type inference is going to impact a lot of code. We can see the impact in the standard library, but we must also remember that it will impact user code, and users will not have Dave Abrahams around to redesign their protocols for them. Now, the standard library *is* a bit of a special case: In some areas—particularly Collection and its ilk—it is very aggressively designed right to the ragged edge of what Swift supports. But in other areas, it is the canary in the coal mine. If we find that, say, FloatingPoint is significantly more burdensome to conform to without redesigning it, that means many protocols in user code will be too. Normally, we ship things incrementally, but here I think we need to make an exception: This proposal will make a gigantic mess, and we cannot ship it until we've cleaned that mess up. That means we ought to think long and hard, right now, about whether September is a reasonable deadline to not only rip out associated types, not only redesign the standard library to clean up the problems it creates, but also add whatever features are necessary to compensate for the removal. And if we don't think we can, we should defer until we have the time to finish the job. -- Brent Royal-Gordon Architechies _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
