Yes, that is what I mean. I forgot that generic protocols were there (probably because they are listed under 'unlikely'). I have bumped into this a couple times now so I would very much like to make a type conform multiple times.
On Wed, May 25, 2016 at 9:46 PM, Austin Zheng <[email protected]> wrote: > 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 ("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]> 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]> 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 <[email protected]> >> Sent: 25/05/2016 07:06 PM >> To: David Hart <[email protected]> >> Cc: Swift-evolution <[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]> 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] >> 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 > > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
