We could have the generic type parameter always shadow the associated type.
> On 26 May 2016, at 06:08, Patrick Smith <pgwsm...@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@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@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