> On May 26, 2016, at 12:37 AM, Leonardo Pessoa via swift-evolution
> <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.
>
You are referring to general inference. The proposal for for associated types
being inferred from conforming methods inside protocol implementations... a
very narro part of the language. And considering the new type aliasing
capabilities, one that we may need even less than before.
> From: Matthew Johnson via swift-evolution
> Sent: 25/05/2016 07:06 PM
> To: David Hart
> Cc: Swift-evolution
> 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> 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
>> Author: David Hart, Douglas Gregor
>> Status: TBD
>> Review manager: TBD
>> Introduction
>>
>> This proposal seeks to remove the inference of associated types in types
>> conforming to protocols.
>>
>> 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:
>>
>> 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.
>>
>> 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
>> }
>> 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.
>>
>>
>
> [The entire original message is not included.]
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
