+1 for the proposal. Another quirk of associated types is that they cannot be overloaded as far as I can tell. Requiring explicit declaration could move us toward allowing multiple types to serve. Does anyone else see this as a useful feature to pursue? TJ
On Wed, May 25, 2016 at 6:33 PM, Sean Heber via swift-evolution < swift-evolution@swift.org> wrote: > This is how I feel as well - I don't understand why we'd want to make the > programmer do more work. Shouldn't the goal for the compiler and language > be to make the end user programmer do *less* work while still getting solid > results? I would like to see more and smarter magic like inference/context > awareness in the language - not less! > > l8r > Sean > > Sent from my iPad > > On May 25, 2016, at 5:37 PM, Leonardo Pessoa via swift-evolution < > swift-evolution@swift.org> wrote: > > -1. I don't really see how this is a bad thing and why it has to change. > To me this is one of the best features of the language and I want more of > it (I've been through some situations it was totally obvious the expected > type of a variable and the compiler couldn't infer it) not less. > > ------------------------------ > From: Matthew Johnson via swift-evolution <swift-evolution@swift.org> > Sent: 25/05/2016 07:06 PM > To: David Hart <da...@hartbit.com> > Cc: Swift-evolution <swift-evolution@swift.org> > Subject: Re: [swift-evolution] [Pitch] Remove associated type inference > > I agree that if we’re going to do it we should probably do it in Swift 3. > But it is a very convenient and useful feature that significantly lowers > the bar of conforming to protocols with associated types (in many cases you > can just implement the required members without thinking about the > associated types). I think we should have a more detailed and compelling > story about why we’re considering this change than I see in this proposal. > > Are there any benefits users might receive from this change (assuming type > checker architecture and bugs could eventually be ironed out)? Is it > actively blocking desirable new features? If so what are they and in what > way are they blocked? > > > On May 25, 2016, at 4:43 PM, David Hart via swift-evolution < > swift-evolution@swift.org> wrote: > > Here’s a pitch for removing associated type inference as per the Generics > Manifesto. If we want to do it, we’d better do it before Swift 3: > > Remove associated type inference > > - Proposal: SE-XXXX > > <https://github.com/apple/swift-evolution/blob/master/proposals/XXXX-remove-associated-type-inference.md> > - Author: David Hart <https://github.com/hartbit>, Douglas Gregor > <https://github.com/DougGregor> > - Status: TBD > - Review manager: TBD > > > <https://github.com/hartbit/swift-evolution/blob/remove-associated-type-inference/proposals/XXXX-remove-associated-type-inference.md#introduction> > Introduction > > This proposal seeks to remove the inference of associated types in types > conforming to protocols. > > <https://github.com/hartbit/swift-evolution/blob/remove-associated-type-inference/proposals/XXXX-remove-associated-type-inference.md#motivation> > Motivation > > Even if associated types inference in a useful feature, it is also a big > source of bugs in the compiler. This proposal argues that the usefulness > does not outweight its architectural complexity. As per the Generics > Manifesto > <https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md>: > > associated type inference is the only place in Swift where we have a > global type inference problem: it has historically been a major source of > bugs, and implementing it fully and correctly requires a drastically > different architecture to the type checker. > > Because this is a breaking change, it would be beneficial to implement it > for Swift 3. > > <https://github.com/hartbit/swift-evolution/blob/remove-associated-type-inference/proposals/XXXX-remove-associated-type-inference.md#detailed-design>Detailed > Design > > The proposal would remove associated type inference and make code which > relied on it invalid: > > protocol IteratorProtocol { > associatedtype Element > mutating func next() -> Element? > } > struct IntIterator : IteratorProtocol { > mutating func next() -> Int? { ... } // used to infer Element = Int > } > > The compiler would generate an error message stating: error: IntIterator > is missing its Element associated type declaration. The code would have > to be modified as follows to fix the error: > > struct IntIterator : IteratorProtocol { > typealias Element = Int > mutating func next() -> Int? { return nil } // used to infer Element = > Int > } > > > <https://github.com/hartbit/swift-evolution/blob/remove-associated-type-inference/proposals/XXXX-remove-associated-type-inference.md#impact-on-existing-code>Impact > on Existing Code > > This is a breaking change that will require conforming types which relied > on the inference, including in the Standard Library, to explicitly declare > associated types. A Fix-It could be introduced to add the typealias and > leave the type to be filled in. That way, all the type inference could be > removed from the compiler. > > <https://github.com/hartbit/swift-evolution/blob/remove-associated-type-inference/proposals/XXXX-remove-associated-type-inference.md#alternatives-considered> > > > [The entire original message is not included.] > > _______________________________________________ > 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 > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution