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

[Matthew Johnson]

> On Jun 28, 2016, at 3:24 PM, Austin Zheng <austinzheng at gmail.com> wrote:
> 
> Inline
> 
> On Mon, Jun 27, 2016 at 6:47 AM, Matthew Johnson <matthew at anandabits.com <mailto:matthew at anandabits.com>> wrote:
> 
> 
> Sent from my iPad
> 
> On Jun 25, 2016, at 12:41 PM, Austin Zheng <austinzheng at gmail.com <mailto:austinzheng at gmail.com>> wrote:
>> I actually think that the delineation between `associatedtype` and `typealias` should make this legal, and will change the proposal as such. It should be legal to bind an associated type to a type alias, and it should be possible to define a type alias that shadows (but does not conflict with) an associated type definition. This would fix the issue with retroactive modeling.
> 
> IIUC you're saying a type is allowed to have an `associatedtype` and `typealias` (or nested type) both bound to the same name as long as they resolve to the same type.  Is that correct?  That would at least preserve current expressiveness.
> 
> Yes, that is exactly correct :).
> 
> I actually have an alternative (see the last sub-entry in the alternative section) that would relax even that restriction. This would actually make the language slightly more expressive, since you would _theoretically_ be able to get around the typealias or nested type aliasing issues that exist today. I argued a bit against it but it's there in case the core team disagrees.
>  
> 
>> 
>>> 
>>> // 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.
>> 
>> Addendum aside, retroactive modeling is already suboptimal or broken in multiple ways today - try conforming a protocol with associated type 'Element' to a different protocol whose 'Element' means something completely different.
> 
> Did you mean conforming a type to two protocols with an 'Element' associatedtype?
> 
> I consider that issue to be in the realm of multiple conformances rather than retroactive modeling.  I can still 
> 
> Yeah, I completely mangled that sentence.
> 
> I think it does fall into the realm of retroactive modeling, since an existing type may be prevented from being retroactively conformed to a new protocol by an existing conformance that it has.

I suppose you can look at it that way.  

Here’s a suggestion for your proposal: if we’re going to go as far as requiring explicit `associatedtype` declarations why not allow disambiguation?  If there are two protocols `Foo` and `Bar` both with an `Element` associated type maybe we should be able to write `Foo.Element` and `Bar.Element` if that is necessary to disambiguate.  This would also work in cases like the one you mention above when reference your alternative, but without introducing two different bindings for the same name.

It wouldn’t have made sense in the current syntax using `typealias` but if we use a declaration that *only* exists for the purpose of conformance it seems like allowing disambiguation is a rather obvious thing to do (once you think of the idea). 

>  
> 
> 
> Thank you for adding the clarifications.  I feel a little better knowing we wouldn't lose expressive power, but still prefer the directed inference suggested by Dmitri.
> 
> 
> And thank you for your honest feedback! 
> 

You’re welcome.  I’m still hoping we find a way out of this (the idea of writing these out for every conformance is a real bummer), but that hope is fading after reading Doug’s reply to Dmitri.  In the end I trust the core team will make the right decision.  It seems like the library folks would prefer to avoid dropping inference so I’m sure there will be a healthy debate by folks who are far more expert on this topic than I.

-Matthew

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160628/af8afc62/attachment.html>