That was my impression as well, but if there's a good argument otherwise I would welcome someone eventually taking it to the proposal stage (probably after Swift 3). Even a formal discussion period followed by a rejection would help us understand if/where the type system is deficient, and perhaps figure out alternative ways to address those areas.
Austin > On May 25, 2016, at 8:57 PM, Matthew Johnson <matt...@anandabits.com> wrote: > > > > Sent from my iPad > > On May 25, 2016, at 10:51 PM, Austin Zheng via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > >> I think a good proposal in this space would allow protocols to specify >> whether they could be implemented only once or multiple times, which would >> address the issues the manifesto raised regarding (e.g.) multiple impls of >> Sequence breaking everything. > > I'm pretty sure the core team is strongly against allowing multiple > implementations of the same protocol by the same type. This isn't the first > time it has been discussed. It tends to come up in conjunction with generic > protocols, but I believe all the same issues are relevant here as well. > >> >> Austin >> >>> On May 25, 2016, at 8:49 PM, T.J. Usiyan <griotsp...@gmail.com >>> <mailto:griotsp...@gmail.com>> wrote: >>> >>> 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 <austinzh...@gmail.com >>> <mailto:austinzh...@gmail.com>> 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 >>> <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 >>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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 >>>> <swift-evolution@swift.org <mailto: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 <mailto: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 >>>>> <mailto:swift-evolution@swift.org> >>>>> Sent: 25/05/2016 07:06 PM >>>>> To: David Hart <mailto:da...@hartbit.com> >>>>> Cc: Swift-evolution <mailto: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 <mailto: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 <mailto:swift-evolution@swift.org> >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>> >>>> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> >>> >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
