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

Haravikk swift-evolution at haravikk.me
Wed May 25 17:40:26 CDT 2016


I’m in favour if it simplifies the type checker, and also I kind of prefer this as I’d rather overriding/implementing methods consistently used associated types. As long as the warning is clear it shouldn’t introduce many problems, and Swift 3 is going to be a transition for most as it is anyway so getting this into Swift 3 shouldn’t represent any major additional burden to anyone.

I know it’s a little bit of an annoyance to declare the associated type for a generator or sequence, but perhaps we could find another way to simplify it again? Declaring basic protocol generics is something that could do with being simplified further anyway as I’d still like to see the ability to declare stuff like this some day:

	protocol FooType<Element> { … }
	struct Foo : FooType<String> { … }

Which I think would serve much the same purpose when it comes to eliminating associatedtype declarations. Anyway that’s a bit off topic, my point is that while it may require the extra line for now, there ought to be ways to solve that in future that don’t require such complex inference.

> On 25 May 2016, at 22:43, 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 <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 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/20160525/ba2757ac/attachment.html>


More information about the swift-evolution mailing list