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 > Sent: 25/05/2016 07:06 PM > To: David Hart > Cc: Swift-evolution > 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 >> Author: David Hart, Douglas Gregor >> Status: TBD >> Review manager: TBD >> Introduction >> >> This proposal seeks to remove the inference of associated types in types >> conforming to protocols. >> >> 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: >> >> 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. >> >> 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 >> } >> 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. >> >> > > [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