Inline
On Mon, Jun 27, 2016 at 6:47 AM, Matthew Johnson <matt...@anandabits.com>
wrote:
>
>
> Sent from my iPad
>
> On Jun 25, 2016, at 12:41 PM, Austin Zheng <austinzh...@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!
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
