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
> <[email protected]> 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
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
