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

Wed May 25 22:49:07 CDT 2016

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> 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 <
> 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> 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> 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 <swift-evolution at swift.org>
>> Sent: ‎25/‎05/‎2016 07:06 PM
>> To: David Hart <david at hartbit.com>
>> Cc: Swift-evolution <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> 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
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> 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/78686462/attachment.html>