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

[Austin Zheng]

Inline

On Mon, Jun 27, 2016 at 6:47 AM, Matthew Johnson <matthew at anandabits.com>
wrote:

>
>
> Sent from my iPad
>
> On Jun 25, 2016, at 12:41 PM, Austin Zheng <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.


>
>
> 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!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160628/61b1536d/attachment.html>