I believe it also helps readability. Associated type are part of the
declaration and I think it's worth pursuing better readability than programmer
friendliness at the declaration. When reading a type declaration that conforms
to a protocol with associated types, I find it refreshing not having to hunt
down the function declaration to figure out what type was inferred as the
associated type. I prefer it when programmers are explicit in this situation.
> On 26 May 2016, at 02:33, Sean Heber <s...@fifthace.com> 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> 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
>> 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
