> On Jun 29, 2016, at 12:33 PM, Chris Lattner via swift-evolution > <swift-evolution@swift.org> wrote: > > Hello Swift community, > > The review of "SE-0108: Remove associated type inference" begins now and runs > through July 4. The proposal is available here: > > > https://github.com/apple/swift-evolution/blob/master/proposals/0108-remove-assoctype-inference.md > > * What is your evaluation of the proposal?
I don’t like the change to using typealias for explicitly binding the type because typealias already has another completely different meaning (introducing a new name) in the identical context. This smacks of the same problem associated types had back when they were spelled typealias. I also understand why using associatedtype is problematic. We do have a keyword that indicates “this thing is not completely new, but actually replaces the received member” override associatedtype Element = String Maybe the objection is verbosity? But it certainly is extremely clear that Element is not a new name being introduced, nor is it introducing a new associatedtype. You could also use “let associatedtype Element = String” if override is too tied up with class inheritance. Binding using a nested type seems odd, though I don’t necessarily object to it. > If associated type inference were to be removed, C.A would be bound as Int > (since there would be no explicit typealias declaration overriding the > default type value), and the doSomething() implementation returning Int would > be considered to fulfill the protocol requirement. Thus, the semantics of the > code listing above would change even though the source itself remained > unchanged. This is problematic to me. This proposal introduces the disambiguation syntax so I would say that the compiler should emit an error if this situation arises and require you to explicitly specify what associated type you are binding, ignoring the protocol’s default. It could still warn on doSomething() to let you know there is a potential pitfall. > * Is the problem being addressed significant enough to warrant a change > to Swift? I believe Doug when he says it has negative implications for the type checker. > * Does this proposal fit well with the feel and direction of Swift? > * How much effort did you put into your review? A glance, a quick > reading, or an in-depth study? Reading and thinking, following the original discussion thread.
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
