[Pitch] Remove associated type inference

[hartbit (David Hart)]

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&gt;
Author: David Hart <https://github.com/hartbit&gt;, Douglas Gregor <https://github.com/DougGregor&gt;
Status: TBD
Review manager: TBD
<https://github.com/hartbit/swift-evolution/blob/remove-associated-type-inference/proposals/XXXX-remove-associated-type-inference.md#introduction&gt;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&gt;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&gt;:

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&gt;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&gt;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&gt;Alternatives Considered

The only alternative is to keep the inference with the known consequences on the compiler.

[gribozavr (Dmitri Gribenko)]

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.

Please show an example -- for example, what a smallest collection type
will look like.

Alternatives Considered

The only alternative is to keep the inference with the known consequences on
the compiler.

Sorry, that's not fair :) There is a middle ground -- limited
inference. For example, in Collection, we don't need Index to be
inferrable from every declaration that mentions it. We can add a
feature to declare that the type of 'var startIndex' infers
'associatedtype Index' (via an appropriate attribute). It is true
that this approach would not remove global inference as such, but it
will make it a much easier problem I believe.

Dmitri

···

On Wed, May 25, 2016 at 2:43 PM, David Hart via swift-evolution <swift-evolution@swift.org> wrote:

--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/

[anandabits (Matthew Johnson)]

I agree that if we’re going to do it we should probably do it in Swift 3. But it is a very convenient and useful feature that significantly lowers the bar of conforming to protocols with associated types (in many cases you can just implement the required members without thinking about the associated types). I think we should have a more detailed and compelling story about why we’re considering this change than I see in this proposal.

Are there any benefits users might receive from this change (assuming type checker architecture and bugs could eventually be ironed out)? Is it actively blocking desirable new features? If so what are they and in what way are they blocked?

···

On May 25, 2016, at 4:43 PM, 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&gt;
Author: David Hart <https://github.com/hartbit&gt;, Douglas Gregor <https://github.com/DougGregor&gt;
Status: TBD
Review manager: TBD
<https://github.com/hartbit/swift-evolution/blob/remove-associated-type-inference/proposals/XXXX-remove-associated-type-inference.md#introduction&gt;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&gt;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&gt;:

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&gt;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&gt;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&gt;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

[BigZaphod (Sean Heber)]

This is how I feel as well - I don't understand why we'd want to make the programmer do more work. Shouldn't the goal for the compiler and language be to make the end user programmer do *less* work while still getting solid results? I would like to see more and smarter magic like inference/context awareness in the language - not less!

l8r
Sean

···

Sent from my iPad

On May 25, 2016, at 5:37 PM, Leonardo Pessoa via swift-evolution <swift-evolution@swift.org> wrote:

-1. I don't really see how this is a bad thing and why it has to change. To me this is one of the best features of the language and I want more of it (I've been through some situations it was totally obvious the expected type of a variable and the compiler couldn't infer it) not less.

From: Matthew Johnson via swift-evolution
Sent: ‎25/‎05/‎2016 07:06 PM
To: David Hart
Cc: Swift-evolution
Subject: Re: [swift-evolution] [Pitch] Remove associated type inference

I agree that if we’re going to do it we should probably do it in Swift 3. But it is a very convenient and useful feature that significantly lowers the bar of conforming to protocols with associated types (in many cases you can just implement the required members without thinking about the associated types). I think we should have a more detailed and compelling story about why we’re considering this change than I see in this proposal.

Are there any benefits users might receive from this change (assuming type checker architecture and bugs could eventually be ironed out)? Is it actively blocking desirable new features? If so what are they and in what way are they blocked?

On May 25, 2016, at 4:43 PM, 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.

[The entire original message is not included.]
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[Lmpessoa (Leonardo Pessoa)]

-1. I don't really see how this is a bad thing and why it has to change. To me this is one of the best features of the language and I want more of it (I've been through some situations it was totally obvious the expected type of a variable and the compiler couldn't infer it) not less.

···

-----Original Message-----
From: "Matthew Johnson via swift-evolution" <swift-evolution@swift.org>
Sent: ‎25/‎05/‎2016 07:06 PM
To: "David Hart" <david@hartbit.com>
Cc: "Swift-evolution" <swift-evolution@swift.org>
Subject: Re: [swift-evolution] [Pitch] Remove associated type inference

I agree that if we’re going to do it we should probably do it in Swift 3. But it is a very convenient and useful feature that significantly lowers the bar of conforming to protocols with associated types (in many cases you can just implement the required members without thinking about the associated types). I think we should have a more detailed and compelling story about why we’re considering this change than I see in this proposal.

Are there any benefits users might receive from this change (assuming type checker architecture and bugs could eventually be ironed out)? Is it actively blocking desirable new features? If so what are they and in what way are they blocked?

On May 25, 2016, at 4:43 PM, 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.
<path d="M4 9h1v1h-1c-1.5 0-3-1.69-3-3.5s1.55-3.5 3-3.5h4c1.45 0 3 1.69 3 3.5 0 1.41-0.91 2.72-2 3.25v-1.16c0.58-0.45 1-1.27 1-2.09 0-1.28-1.02-2.5-2-2.5H4c-0.98 0-2 1.22-2 2.5s1 2.5 2 2.5z m9-3h-1v1h1c1 0 2 1.22 2 2.5s-1.02 2.5-2 2.5H9c-0.98 0-2-1.22-2-2.5 0-0.83 0.42-1.64 1-2.09v-1.16c-1.09 0.53-2 1.84-2 3.25 0 1.81 1.55 3.5 3 3.5h4c1.45 0 3-1.69 3-3.5s-1.5-3.5-3-3.5z"

[The entire original message is not included.]

[Austin (Austin Zheng)]

Do you mean allowing a type to conform to a protocol multiple times with a different set of types each time? That's an interesting idea; the generics manifesto describes the same feature but implemented using generics: https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md ("Generic Protocols").

···

On May 25, 2016, at 8:43 PM, T.J. Usiyan via swift-evolution <swift-evolution@swift.org> wrote:

+1 for the proposal.

Another quirk of associated types is that they cannot be overloaded as far as I can tell. Requiring explicit declaration could move us toward allowing multiple types to serve. Does anyone else see this as a useful feature to pursue?
TJ

On Wed, May 25, 2016 at 6:33 PM, Sean Heber via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
This is how I feel as well - I don't understand why we'd want to make the programmer do more work. Shouldn't the goal for the compiler and language be to make the end user programmer do *less* work while still getting solid results? I would like to see more and smarter magic like inference/context awareness in the language - not less!

l8r
Sean

Sent from my iPad

On May 25, 2016, at 5:37 PM, Leonardo Pessoa via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

-1. I don't really see how this is a bad thing and why it has to change. To me this is one of the best features of the language and I want more of it (I've been through some situations it was totally obvious the expected type of a variable and the compiler couldn't infer it) not less.

From: Matthew Johnson via swift-evolution <mailto:swift-evolution@swift.org>
Sent: ‎25/‎05/‎2016 07:06 PM
To: David Hart <mailto:david@hartbit.com>
Cc: Swift-evolution <mailto:swift-evolution@swift.org>
Subject: Re: [swift-evolution] [Pitch] Remove associated type inference

I agree that if we’re going to do it we should probably do it in Swift 3. But it is a very convenient and useful feature that significantly lowers the bar of conforming to protocols with associated types (in many cases you can just implement the required members without thinking about the associated types). I think we should have a more detailed and compelling story about why we’re considering this change than I see in this proposal.

Are there any benefits users might receive from this change (assuming type checker architecture and bugs could eventually be ironed out)? Is it actively blocking desirable new features? If so what are they and in what way are they blocked?

On May 25, 2016, at 4:43 PM, David Hart via swift-evolution <swift-evolution@swift.org <mailto: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&gt;
Author: David Hart <https://github.com/hartbit&gt;, Douglas Gregor <https://github.com/DougGregor&gt;
Status: TBD
Review manager: TBD
<https://github.com/hartbit/swift-evolution/blob/remove-associated-type-inference/proposals/XXXX-remove-associated-type-inference.md#introduction&gt;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&gt;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&gt;:

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&gt;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&gt;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&gt;

[The entire original message is not included.]
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto: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

[Austin (Austin Zheng)]

I think a good proposal in this space would allow protocols to specify whether they could be implemented only once or multiple times, which would address the issues the manifesto raised regarding (e.g.) multiple impls of Sequence breaking everything.

Austin

···

On May 25, 2016, at 8:49 PM, T.J. Usiyan <griotspeak@gmail.com> wrote:

Yes, that is what I mean. I forgot that generic protocols were there (probably because they are listed under 'unlikely'). I have bumped into this a couple times now so I would very much like to make a type conform multiple times.

On Wed, May 25, 2016 at 9:46 PM, Austin Zheng <austinzheng@gmail.com <mailto:austinzheng@gmail.com>> wrote:
Do you mean allowing a type to conform to a protocol multiple times with a different set of types each time? That's an interesting idea; the generics manifesto describes the same feature but implemented using generics: https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md ("Generic Protocols").

On May 25, 2016, at 8:43 PM, T.J. Usiyan via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

+1 for the proposal.

Another quirk of associated types is that they cannot be overloaded as far as I can tell. Requiring explicit declaration could move us toward allowing multiple types to serve. Does anyone else see this as a useful feature to pursue?
TJ

On Wed, May 25, 2016 at 6:33 PM, Sean Heber via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
This is how I feel as well - I don't understand why we'd want to make the programmer do more work. Shouldn't the goal for the compiler and language be to make the end user programmer do *less* work while still getting solid results? I would like to see more and smarter magic like inference/context awareness in the language - not less!

l8r
Sean

Sent from my iPad

On May 25, 2016, at 5:37 PM, Leonardo Pessoa via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

-1. I don't really see how this is a bad thing and why it has to change. To me this is one of the best features of the language and I want more of it (I've been through some situations it was totally obvious the expected type of a variable and the compiler couldn't infer it) not less.

From: Matthew Johnson via swift-evolution <mailto:swift-evolution@swift.org>
Sent: ‎25/‎05/‎2016 07:06 PM
To: David Hart <mailto:david@hartbit.com>
Cc: Swift-evolution <mailto:swift-evolution@swift.org>
Subject: Re: [swift-evolution] [Pitch] Remove associated type inference

I agree that if we’re going to do it we should probably do it in Swift 3. But it is a very convenient and useful feature that significantly lowers the bar of conforming to protocols with associated types (in many cases you can just implement the required members without thinking about the associated types). I think we should have a more detailed and compelling story about why we’re considering this change than I see in this proposal.

Are there any benefits users might receive from this change (assuming type checker architecture and bugs could eventually be ironed out)? Is it actively blocking desirable new features? If so what are they and in what way are they blocked?

On May 25, 2016, at 4:43 PM, David Hart via swift-evolution <swift-evolution@swift.org <mailto: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&gt;
Author: David Hart <https://github.com/hartbit&gt;, Douglas Gregor <https://github.com/DougGregor&gt;
Status: TBD
Review manager: TBD
<https://github.com/hartbit/swift-evolution/blob/remove-associated-type-inference/proposals/XXXX-remove-associated-type-inference.md#introduction&gt;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&gt;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&gt;:

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&gt;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&gt;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&gt;

[The entire original message is not included.]
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

[Austin (Austin Zheng)]

That was my impression as well, but if there's a good argument otherwise I would welcome someone eventually taking it to the proposal stage (probably after Swift 3). Even a formal discussion period followed by a rejection would help us understand if/where the type system is deficient, and perhaps figure out alternative ways to address those areas.

Austin

···

On May 25, 2016, at 8:57 PM, Matthew Johnson <matthew@anandabits.com> wrote:

Sent from my iPad

On May 25, 2016, at 10:51 PM, Austin Zheng via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I think a good proposal in this space would allow protocols to specify whether they could be implemented only once or multiple times, which would address the issues the manifesto raised regarding (e.g.) multiple impls of Sequence breaking everything.

I'm pretty sure the core team is strongly against allowing multiple implementations of the same protocol by the same type. This isn't the first time it has been discussed. It tends to come up in conjunction with generic protocols, but I believe all the same issues are relevant here as well.

Austin

On May 25, 2016, at 8:49 PM, T.J. Usiyan <griotspeak@gmail.com <mailto:griotspeak@gmail.com>> wrote:

Yes, that is what I mean. I forgot that generic protocols were there (probably because they are listed under 'unlikely'). I have bumped into this a couple times now so I would very much like to make a type conform multiple times.

On Wed, May 25, 2016 at 9:46 PM, Austin Zheng <austinzheng@gmail.com <mailto:austinzheng@gmail.com>> wrote:
Do you mean allowing a type to conform to a protocol multiple times with a different set of types each time? That's an interesting idea; the generics manifesto describes the same feature but implemented using generics: https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md ("Generic Protocols").

On May 25, 2016, at 8:43 PM, T.J. Usiyan via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

+1 for the proposal.

Another quirk of associated types is that they cannot be overloaded as far as I can tell. Requiring explicit declaration could move us toward allowing multiple types to serve. Does anyone else see this as a useful feature to pursue?
TJ

On Wed, May 25, 2016 at 6:33 PM, Sean Heber via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
This is how I feel as well - I don't understand why we'd want to make the programmer do more work. Shouldn't the goal for the compiler and language be to make the end user programmer do *less* work while still getting solid results? I would like to see more and smarter magic like inference/context awareness in the language - not less!

l8r
Sean

Sent from my iPad

On May 25, 2016, at 5:37 PM, Leonardo Pessoa via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

-1. I don't really see how this is a bad thing and why it has to change. To me this is one of the best features of the language and I want more of it (I've been through some situations it was totally obvious the expected type of a variable and the compiler couldn't infer it) not less.

From: Matthew Johnson via swift-evolution <mailto:swift-evolution@swift.org>
Sent: ‎25/‎05/‎2016 07:06 PM
To: David Hart <mailto:david@hartbit.com>
Cc: Swift-evolution <mailto:swift-evolution@swift.org>
Subject: Re: [swift-evolution] [Pitch] Remove associated type inference

I agree that if we’re going to do it we should probably do it in Swift 3. But it is a very convenient and useful feature that significantly lowers the bar of conforming to protocols with associated types (in many cases you can just implement the required members without thinking about the associated types). I think we should have a more detailed and compelling story about why we’re considering this change than I see in this proposal.

Are there any benefits users might receive from this change (assuming type checker architecture and bugs could eventually be ironed out)? Is it actively blocking desirable new features? If so what are they and in what way are they blocked?

On May 25, 2016, at 4:43 PM, David Hart via swift-evolution <swift-evolution@swift.org <mailto: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&gt;
Author: David Hart <https://github.com/hartbit&gt;, Douglas Gregor <https://github.com/DougGregor&gt;
Status: TBD
Review manager: TBD
<https://github.com/hartbit/swift-evolution/blob/remove-associated-type-inference/proposals/XXXX-remove-associated-type-inference.md#introduction&gt;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&gt;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&gt;:

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&gt;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&gt;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&gt;

[The entire original message is not included.]
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

[griotspeak (TJ Usiyan)]

+1 for the proposal.

Another quirk of associated types is that they cannot be overloaded as far
as I can tell. Requiring explicit declaration could move us toward allowing
multiple types to serve. Does anyone else see this as a useful feature to
pursue?
TJ

···

On Wed, May 25, 2016 at 6:33 PM, Sean Heber via swift-evolution < swift-evolution@swift.org> wrote:

This is how I feel as well - I don't understand why we'd want to make the
programmer do more work. Shouldn't the goal for the compiler and language
be to make the end user programmer do *less* work while still getting solid
results? I would like to see more and smarter magic like inference/context
awareness in the language - not less!

l8r
Sean

Sent from my iPad

On May 25, 2016, at 5:37 PM, Leonardo Pessoa via swift-evolution < > swift-evolution@swift.org> wrote:

-1. I don't really see how this is a bad thing and why it has to change.
To me this is one of the best features of the language and I want more of
it (I've been through some situations it was totally obvious the expected
type of a variable and the compiler couldn't infer it) not less.

------------------------------
From: Matthew Johnson via swift-evolution <swift-evolution@swift.org>
Sent: ‎25/‎05/‎2016 07:06 PM
To: David Hart <david@hartbit.com>
Cc: Swift-evolution <swift-evolution@swift.org>
Subject: Re: [swift-evolution] [Pitch] Remove associated type inference

I agree that if we’re going to do it we should probably do it in Swift 3.
But it is a very convenient and useful feature that significantly lowers
the bar of conforming to protocols with associated types (in many cases you
can just implement the required members without thinking about the
associated types). I think we should have a more detailed and compelling
story about why we’re considering this change than I see in this proposal.

Are there any benefits users might receive from this change (assuming type
checker architecture and bugs could eventually be ironed out)? Is it
actively blocking desirable new features? If so what are they and in what
way are they blocked?

On May 25, 2016, at 4:43 PM, 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&gt;
   - Author: David Hart <https://github.com/hartbit&gt;, Douglas Gregor
   <https://github.com/DougGregor&gt;
   - Status: TBD
   - Review manager: TBD

<https://github.com/hartbit/swift-evolution/blob/remove-associated-type-inference/proposals/XXXX-remove-associated-type-inference.md#introduction&gt;
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&gt;
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&gt;:

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&gt;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&gt;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&gt;

[The entire original message is not included.]

_______________________________________________
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

[griotspeak (TJ Usiyan)]

Yes, that is what I mean. I forgot that generic protocols were there
(probably because they are listed under 'unlikely'). I have bumped into
this a couple times now so I would very much like to make a type conform
multiple times.

···

On Wed, May 25, 2016 at 9:46 PM, Austin Zheng <austinzheng@gmail.com> wrote:

Do you mean allowing a type to conform to a protocol multiple times with a
different set of types each time? That's an interesting idea; the generics
manifesto describes the same feature but implemented using generics:
https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md ("Generic
Protocols").

On May 25, 2016, at 8:43 PM, T.J. Usiyan via swift-evolution < > swift-evolution@swift.org> wrote:

+1 for the proposal.

Another quirk of associated types is that they cannot be overloaded as far
as I can tell. Requiring explicit declaration could move us toward allowing
multiple types to serve. Does anyone else see this as a useful feature to
pursue?
TJ

On Wed, May 25, 2016 at 6:33 PM, Sean Heber via swift-evolution < > swift-evolution@swift.org> wrote:

This is how I feel as well - I don't understand why we'd want to make the
programmer do more work. Shouldn't the goal for the compiler and language
be to make the end user programmer do *less* work while still getting solid
results? I would like to see more and smarter magic like inference/context
awareness in the language - not less!

l8r
Sean

Sent from my iPad

On May 25, 2016, at 5:37 PM, Leonardo Pessoa via swift-evolution < >> swift-evolution@swift.org> wrote:

-1. I don't really see how this is a bad thing and why it has to change.
To me this is one of the best features of the language and I want more of
it (I've been through some situations it was totally obvious the expected
type of a variable and the compiler couldn't infer it) not less.

------------------------------
From: Matthew Johnson via swift-evolution <swift-evolution@swift.org>
Sent: ‎25/‎05/‎2016 07:06 PM
To: David Hart <david@hartbit.com>
Cc: Swift-evolution <swift-evolution@swift.org>
Subject: Re: [swift-evolution] [Pitch] Remove associated type inference

I agree that if we’re going to do it we should probably do it in Swift
3. But it is a very convenient and useful feature that significantly
lowers the bar of conforming to protocols with associated types (in many
cases you can just implement the required members without thinking about
the associated types). I think we should have a more detailed and
compelling story about why we’re considering this change than I see in this
proposal.

Are there any benefits users might receive from this change (assuming
type checker architecture and bugs could eventually be ironed out)? Is it
actively blocking desirable new features? If so what are they and in what
way are they blocked?

On May 25, 2016, at 4:43 PM, 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&gt;
   - Author: David Hart <https://github.com/hartbit&gt;, Douglas Gregor
   <https://github.com/DougGregor&gt;
   - Status: TBD
   - Review manager: TBD

<https://github.com/hartbit/swift-evolution/blob/remove-associated-type-inference/proposals/XXXX-remove-associated-type-inference.md#introduction&gt;
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&gt;
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&gt;:

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&gt;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&gt;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&gt;

[The entire original message is not included.]

_______________________________________________
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

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[anandabits (Matthew Johnson)]

I think a good proposal in this space would allow protocols to specify whether they could be implemented only once or multiple times, which would address the issues the manifesto raised regarding (e.g.) multiple impls of Sequence breaking everything.

I'm pretty sure the core team is strongly against allowing multiple implementations of the same protocol by the same type. This isn't the first time it has been discussed. It tends to come up in conjunction with generic protocols, but I believe all the same issues are relevant here as well.

···

Sent from my iPad

On May 25, 2016, at 10:51 PM, Austin Zheng via swift-evolution <swift-evolution@swift.org> wrote:

Austin

On May 25, 2016, at 8:49 PM, T.J. Usiyan <griotspeak@gmail.com> wrote:

Yes, that is what I mean. I forgot that generic protocols were there (probably because they are listed under 'unlikely'). I have bumped into this a couple times now so I would very much like to make a type conform multiple times.

On Wed, May 25, 2016 at 9:46 PM, Austin Zheng <austinzheng@gmail.com> wrote:
Do you mean allowing a type to conform to a protocol multiple times with a different set of types each time? That's an interesting idea; the generics manifesto describes the same feature but implemented using generics: https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md ("Generic Protocols").

On May 25, 2016, at 8:43 PM, T.J. Usiyan via swift-evolution <swift-evolution@swift.org> wrote:

+1 for the proposal.

Another quirk of associated types is that they cannot be overloaded as far as I can tell. Requiring explicit declaration could move us toward allowing multiple types to serve. Does anyone else see this as a useful feature to pursue?
TJ

On Wed, May 25, 2016 at 6:33 PM, Sean Heber via swift-evolution <swift-evolution@swift.org> wrote:
This is how I feel as well - I don't understand why we'd want to make the programmer do more work. Shouldn't the goal for the compiler and language be to make the end user programmer do *less* work while still getting solid results? I would like to see more and smarter magic like inference/context awareness in the language - not less!

l8r
Sean

Sent from my iPad

On May 25, 2016, at 5:37 PM, Leonardo Pessoa via swift-evolution <swift-evolution@swift.org> wrote:

-1. I don't really see how this is a bad thing and why it has to change. To me this is one of the best features of the language and I want more of it (I've been through some situations it was totally obvious the expected type of a variable and the compiler couldn't infer it) not less.

From: Matthew Johnson via swift-evolution
Sent: ‎25/‎05/‎2016 07:06 PM
To: David Hart
Cc: Swift-evolution
Subject: Re: [swift-evolution] [Pitch] Remove associated type inference

I agree that if we’re going to do it we should probably do it in Swift 3. But it is a very convenient and useful feature that significantly lowers the bar of conforming to protocols with associated types (in many cases you can just implement the required members without thinking about the associated types). I think we should have a more detailed and compelling story about why we’re considering this change than I see in this proposal.

Are there any benefits users might receive from this change (assuming type checker architecture and bugs could eventually be ironed out)? Is it actively blocking desirable new features? If so what are they and in what way are they blocked?

On May 25, 2016, at 4:43 PM, 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.

[The entire original message is not included.]
_______________________________________________
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

_______________________________________________
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

[Haravikk3 (Haravikk)]

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@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&gt;
Author: David Hart <https://github.com/hartbit&gt;, Douglas Gregor <https://github.com/DougGregor&gt;
Status: TBD
Review manager: TBD
<https://github.com/hartbit/swift-evolution/blob/remove-associated-type-inference/proposals/XXXX-remove-associated-type-inference.md#introduction&gt;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&gt;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&gt;:

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&gt;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&gt;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&gt;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

[hartbit (David Hart)]

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.

Please show an example -- for example, what a smallest collection type
will look like.

Isn’t that the example in the Detailed Design section? What other example were you thinking of?

Alternatives Considered

The only alternative is to keep the inference with the known consequences on
the compiler.

Sorry, that's not fair :) There is a middle ground -- limited
inference. For example, in Collection, we don't need Index to be
inferrable from every declaration that mentions it. We can add a
feature to declare that the type of 'var startIndex' infers
'associatedtype Index' (via an appropriate attribute). It is true
that this approach would not remove global inference as such, but it
will make it a much easier problem I believe.

This sounds like a more complicated solution: it does not remove global inference and complicates the language with an additional attribute only to help the compiler. I don’t see many advantages to this solution.

···

On 25 May 2016, at 23:47, Dmitri Gribenko <gribozavr@gmail.com> wrote:
On Wed, May 25, 2016 at 2:43 PM, David Hart via swift-evolution > <swift-evolution@swift.org> wrote:

[Panajev (Goffredo Marocchi)]

Operator overloading and type inference are powerful, but very very easy to abuse tools especially in a professional environment with opinionated programmers working on a medium to large codebase. It makes the code written depend greatly from context which may be located far away from when it is used and in some cases in a non obvious way. The result is code less clearer to read, review, and to debug if things go wrong. I think we should always keep in mind the time when people will need to debug our code and make that job easy.

···

Sent from my iPhone

On 25 May 2016, at 23:37, Leonardo Pessoa via swift-evolution <swift-evolution@swift.org> wrote:

-1. I don't really see how this is a bad thing and why it has to change. To me this is one of the best features of the language and I want more of it (I've been through some situations it was totally obvious the expected type of a variable and the compiler couldn't infer it) not less.

From: Matthew Johnson via swift-evolution
Sent: ‎25/‎05/‎2016 07:06 PM
To: David Hart
Cc: Swift-evolution
Subject: Re: [swift-evolution] [Pitch] Remove associated type inference

I agree that if we’re going to do it we should probably do it in Swift 3. But it is a very convenient and useful feature that significantly lowers the bar of conforming to protocols with associated types (in many cases you can just implement the required members without thinking about the associated types). I think we should have a more detailed and compelling story about why we’re considering this change than I see in this proposal.

Are there any benefits users might receive from this change (assuming type checker architecture and bugs could eventually be ironed out)? Is it actively blocking desirable new features? If so what are they and in what way are they blocked?

On May 25, 2016, at 4:43 PM, 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.

[The entire original message is not included.]
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[hartbit (David Hart)]

I believe it also helps readability. Associated type are part of the declaration and I think it's worth pursuing better readability than programmer friendliness at the declaration. When reading a type declaration that conforms to a protocol with associated types, I find it refreshing not having to hunt down the function declaration to figure out what type was inferred as the associated type. I prefer it when programmers are explicit in this situation.

···

On 26 May 2016, at 02:33, Sean Heber <sean@fifthace.com> wrote:

This is how I feel as well - I don't understand why we'd want to make the programmer do more work. Shouldn't the goal for the compiler and language be to make the end user programmer do *less* work while still getting solid results? I would like to see more and smarter magic like inference/context awareness in the language - not less!

l8r
Sean

Sent from my iPad

On May 25, 2016, at 5:37 PM, Leonardo Pessoa via swift-evolution <swift-evolution@swift.org> wrote:

-1. I don't really see how this is a bad thing and why it has to change. To me this is one of the best features of the language and I want more of it (I've been through some situations it was totally obvious the expected type of a variable and the compiler couldn't infer it) not less.

From: Matthew Johnson via swift-evolution
Sent: ‎25/‎05/‎2016 07:06 PM
To: David Hart
Cc: Swift-evolution
Subject: Re: [swift-evolution] [Pitch] Remove associated type inference

I agree that if we’re going to do it we should probably do it in Swift 3. But it is a very convenient and useful feature that significantly lowers the bar of conforming to protocols with associated types (in many cases you can just implement the required members without thinking about the associated types). I think we should have a more detailed and compelling story about why we’re considering this change than I see in this proposal.

Are there any benefits users might receive from this change (assuming type checker architecture and bugs could eventually be ironed out)? Is it actively blocking desirable new features? If so what are they and in what way are they blocked?

On May 25, 2016, at 4:43 PM, 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.

[The entire original message is not included.]
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[Patrick_Smith]

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&gt;
Author: David Hart <https://github.com/hartbit&gt;, Douglas Gregor <https://github.com/DougGregor&gt;
Status: TBD
Review manager: TBD
<https://github.com/hartbit/swift-evolution/blob/remove-associated-type-inference/proposals/XXXX-remove-associated-type-inference.md#introduction&gt;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&gt;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&gt;:

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&gt;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&gt;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&gt;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

[David_Sweeris]

I’m inclined to say -1, for reasons that’ve already been mentioned, but can anyone elaborate on “a drastically different architecture to the type checker”?

- Dave Sweeris

···

On May 25, 2016, at 4:43 PM, 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&gt;
Author: David Hart <https://github.com/hartbit&gt;, Douglas Gregor <https://github.com/DougGregor&gt;
Status: TBD
Review manager: TBD
<https://github.com/hartbit/swift-evolution/blob/remove-associated-type-inference/proposals/XXXX-remove-associated-type-inference.md#introduction&gt;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&gt;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&gt;:

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&gt;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&gt;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&gt;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

[L_Mihalkovic]

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:

From a purely english syntax viewpoint, i would prefer the error to be along the lines of

IntIterator is missing a declaration for the Element associated type

Or

···

On May 25, 2016, at 11:43 PM, David Hart via swift-evolution <swift-evolution@swift.org> wrote:

IntIterator is missing a declaration for its Element associated type

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

[L_Mihalkovic]

-1. I don't really see how this is a bad thing and why it has to change. To me this is one of the best features of the language and I want more of it (I've been through some situations it was totally obvious the expected type of a variable and the compiler couldn't infer it) not less.

You are referring to general inference. The proposal for for associated types being inferred from conforming methods inside protocol implementations... a very narro part of the language. And considering the new type aliasing capabilities, one that we may need even less than before.

···

On May 26, 2016, at 12:37 AM, Leonardo Pessoa via swift-evolution <swift-evolution@swift.org> wrote:

From: Matthew Johnson via swift-evolution
Sent: ‎25/‎05/‎2016 07:06 PM
To: David Hart
Cc: Swift-evolution
Subject: Re: [swift-evolution] [Pitch] Remove associated type inference

I agree that if we’re going to do it we should probably do it in Swift 3. But it is a very convenient and useful feature that significantly lowers the bar of conforming to protocols with associated types (in many cases you can just implement the required members without thinking about the associated types). I think we should have a more detailed and compelling story about why we’re considering this change than I see in this proposal.

Are there any benefits users might receive from this change (assuming type checker architecture and bugs could eventually be ironed out)? Is it actively blocking desirable new features? If so what are they and in what way are they blocked?

On May 25, 2016, at 4:43 PM, 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.

[The entire original message is not included.]
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[gribozavr (Dmitri Gribenko)]

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.

Please show an example -- for example, what a smallest collection type
will look like.

Isn’t that the example in the Detailed Design section? What other example were you thinking of?

You are showing an iterator. Try doing a collection, it has many more
associated types most of which are defaulted.

Alternatives Considered

The only alternative is to keep the inference with the known consequences on
the compiler.

Sorry, that's not fair :) There is a middle ground -- limited
inference. For example, in Collection, we don't need Index to be
inferrable from every declaration that mentions it. We can add a
feature to declare that the type of 'var startIndex' infers
'associatedtype Index' (via an appropriate attribute). It is true
that this approach would not remove global inference as such, but it
will make it a much easier problem I believe.

This sounds like a more complicated solution: it does not remove global inference and complicates the language with an additional attribute only to help the compiler. I don’t see many advantages to this solution.

The advantage is that we can keep the boilerplate down, and make the
problem easier in the compiler.

Dmitri

···

On Wed, May 25, 2016 at 2:52 PM, David Hart <david@hartbit.com> wrote:

On 25 May 2016, at 23:47, Dmitri Gribenko <gribozavr@gmail.com> wrote:
On Wed, May 25, 2016 at 2:43 PM, David Hart via swift-evolution >> <swift-evolution@swift.org> wrote:

--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/