Do you mean allowing a type to conform to a protocol multiple times with a different set of types each time? That's an interesting idea; the generics manifesto describes the same feature but implemented using generics: https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md <https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md> ("Generic Protocols").
> On May 25, 2016, at 8:43 PM, T.J. Usiyan via swift-evolution > <[email protected]> wrote: > > +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 > <[email protected] <mailto:[email protected]>> 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 > <[email protected] <mailto:[email protected]>> 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 <mailto:[email protected]> >> Sent: 25/05/2016 07:06 PM >> To: David Hart <mailto:[email protected]> >> Cc: Swift-evolution <mailto:[email protected]> >> 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 >>> <[email protected] <mailto:[email protected]>> 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 >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> > > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution> > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
