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

[T.J. 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 at 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 at 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 at swift.org>
> Sent: ‎25/‎05/‎2016 07:06 PM
> To: David Hart <david at hartbit.com>
> Cc: Swift-evolution <swift-evolution at 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 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>
>
>
> [The entire original message is not included.]
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> _______________________________________________
> 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/a13da071/attachment-0001.html>