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

[David Hart]

We could have the generic type parameter always shadow the associated type.

> On 26 May 2016, at 06:08, Patrick Smith <pgwsmith at gmail.com> wrote:
> 
> While this has been a handy feature, I don’t mind making things more explicit, as I think it helps communication. Sometimes clarity that helps the compiler will also help the reader. It’s only really convenient when writing.
> 
> I would be happy with this change as long as the issue with same named generics were changed. Currently in Swift 2.2 I can’t do this:
> 
> struct SomeGenericGenerator<Element> : GeneratorType {
>   typealias Element = Element // Error: Type alias ‘Element’ circularly references itself
> }
> 
> It’s a real pain, as now I have to think up some alternate name for the generic parameter ‘Element’.
> 
> Whereas, with automatic inference, I can do this without the compiler complaining:
> 
> struct SomeGenericGenerator<Element> : GeneratorType {
>   mutating func next() -> Element? {
>     return nil
>   }
> }
> 
> So I’d like to see the above `typealias Element = Element` allowed if possible.
> 
> 
>> On 26 May 2016, at 7:43 AM, 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
>> 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.
>> 
>> Alternatives Considered
>> 
>> The only alternative is to keep the inference with the known consequences on the compiler.
>> _______________________________________________
>> 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/20160526/d6df8679/attachment.html>