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@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>Alternatives > Considered > > The only alternative is to keep the inference with the known consequences on > the compiler. > _______________________________________________ > 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