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

[David Hart]

Hi Matthew,

I really like this proposal (even outside of its goal to simplify the type inference engine). The two other motivations in the proposal make very good points which can not be easily dismissed (especially to me as it took me a while to understand associated types):
It improves the type system's function as a form of code documentation by making it very clear to readers of a type declaration how the type's associated types are defined.

It makes it significantly easier for those learning the language to understand how associated types work.

I added some more comments inline your email:

> On 25 Jun 2016, at 15:23, Matthew Johnson via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Hi Austin,
> 
> I’m sorry to say, but this proposal makes me really sad.  I consider associated type inference one of the more elegant aspects of Swift.  It would be very unfortunate to lose it.  
> 
> I am really pleased to see that Dmitri has offered an alternative that looks very reasonable.  I’m hoping the Doug or Chris (or someone else from the core team) can chime in on the feasibility of this alternative.  If it is considered viable and Dmitri isn’t able to write the proposal I would be happy to do so.

For me, this solution is worse than the current status quo. A feature (inference) which works only in certain cases but not all can be very confusing.

> If the alternative isn’t viable and we must proceed with a proposal to remove inference I think there is one crucial thing to consider that isn’t discussed in this proposal: retroactive modeling.  As far as I can tell, this proposal will *prohibit* some types from conforming to some protocols.  Specifically, if a type defines a typealias with a name that matches the name of an associatedtype in a protocol it would not be possible to retroactively model that protocol.  Because of the name conflict an associatedtype declaration would not be allowed and the existing typealias would not meet the requirement.  Consider this example:
> 
> // Module A
> public struct S {
>     public typealias Foo = Int
> }
> 
> // Module B
> public protocol P {
>     associatedtype Foo
> }
> 
> // Module C
> import A
> import B
> 
> // compiler error: `S` does not meet the `Foo` associatedtype requirement
> extension S : P {
>     // compiler error: cannot define associatedtype `Foo` for `S` which already declares typealias `Foo`
>     associatedtype Foo = String
> }
> 
> I cannot support any proposal that breaks retroactive modeling in this way.

This is noteworthy, but solutions can be found. And we already have the problem today:

protocol Foo {
    associatedtype Baz : Integer
}

struct Bar {
    struct Baz { }
}

There’s no way to make Bar conform to Foo (that I know of).

> Another item that is not mentioned in this proposal is that typealias is not the only way to meet an associatedtype requirement in the language today.  For example, this code is legal:
> 
> protocol Foo {
>     associatedtype Bar
> }
> struct S : Foo {
>     struct Bar {}
> }
> 
> If we *must* drop inference I prefer the alternative of just doing that: dropping inference, but otherwise leaving things alone.  All associated type requirements would need to be explicitly satisfied using one of the mechanisms that is currently valid for satisfying a non-inferred associated type requirement.  The ability to satisfy these requirements in a variety of ways is a *benefit* that provides valuable flexibility.
> 
> I agree that something should look for a good solution to the subclass typealias issue, but I don’t think this is it.  Ideally we would find a solution that works well in the presence of retroactive modeling making code such as the following valid:
> 
> // module A
> protocol P1 {
>     associatedtype Foo
> 
>    @infers(Foo)
>     var foo: Foo { get }
> }
> // module B
> protocol P2 {
>     associatedtype Foo
> 
>     @infers(Foo)
>     func bar() -> Foo
> }
> 
> // module C
> class Base {
>     let foo: String = "foo"
> }
> class Derived : Base {
>     func bar() -> Int { return 42 }
> }
> 
> // module D
> import A
> import B
> import C
> import D
> extension Base : P1 {}
> extension Derived : P2 {}
> 
> We don’t always control the protocol or type definitions we want to make work together.  The ability to make code that “should work together” actually do so with minimal fuss is one of the great things about Swift.  Any time we interfere with retroactive modeling we increase the need for boilerplate adapter types, etc.
> 
> One detail appears to be implied by the proposal but isn’t explicitly stated.  Specifically, it looks like the intent is that other than only being valid when used to meet a protocol requirement, associatedtype otherwise works like a typealias.  It would be good to have this behavior clarified if the proposal moves forward.

It looks like it, but it makes it clear that its there to satisfy an associated type. Its documentation.

> -Matthew
> 
> 
> 
>> On Jun 25, 2016, at 12:50 AM, Austin Zheng via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> Hello all,
>> 
>> Per Chris Lattner's list of open Swift 3 design topics (http://article.gmane.org/gmane.comp.lang.swift.evolution/21369 <http://article.gmane.org/gmane.comp.lang.swift.evolution/21369>), I've put together a proposal for removing type inference for associated types.
>> 
>> It can be found here: https://github.com/austinzheng/swift-evolution/blob/az-assoctypeinf/proposals/XXXX-remove-assoctype-inference.md <https://github.com/austinzheng/swift-evolution/blob/az-assoctypeinf/proposals/XXXX-remove-assoctype-inference.md>
>> 
>> Thoughts, criticism, and feedback welcome. There are at least two slightly different designs in the proposal, and I'm sure people will have ideas for even more.
>> 
>> Best,
>> Austin
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto: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/20160625/72f6f483/attachment-0001.html>