[swift-evolution] [Pitch] Remove associated type inference

Wed May 25 22:51:39 CDT 2016

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.

Austin

> On May 25, 2016, at 8:49 PM, T.J. Usiyan <griotspeak at 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 <austinzheng at gmail.com <mailto:austinzheng at 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 at swift.org <mailto:swift-evolution at 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 at swift.org <mailto:swift-evolution at 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 at swift.org <mailto:swift-evolution at 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 at swift.org>
>>> Sent: ‎25/‎05/‎2016 07:06 PM
>>> To: David Hart <mailto:david at hartbit.com>
>>> Cc: Swift-evolution <mailto:swift-evolution at 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 at swift.org <mailto:swift-evolution at 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 at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160525/65df3e73/attachment.html>