<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jun 28, 2016, at 3:24 PM, Austin Zheng &lt;<a href="mailto:austinzheng@gmail.com" class="">austinzheng@gmail.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Inline<br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Mon, Jun 27, 2016 at 6:47 AM, Matthew Johnson <span dir="ltr" class="">&lt;<a href="mailto:matthew@anandabits.com" target="_blank" class="">matthew@anandabits.com</a>&gt;</span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto" class=""><div class=""><br class=""><br class="">Sent from my iPad</div><span class=""><div class=""><br class="">On Jun 25, 2016, at 12:41 PM, Austin Zheng &lt;<a href="mailto:austinzheng@gmail.com" target="_blank" class="">austinzheng@gmail.com</a>&gt; wrote:</div></span><span class=""><blockquote type="cite" class=""><div class=""><div class=""><div class="">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.</div></div></div></blockquote><div class=""><br class=""></div></span>IIUC you're saying a type is allowed to have an <span style="background-color:rgba(255,255,255,0)" class="">`associatedtype` and `typealias` (or nested type) both bound to the same name as long as they resolve to the same type.&nbsp; Is that correct?&nbsp; That would at least preserve current expressiveness.</span></div></blockquote><div class=""><br class=""></div><div class="">Yes, that is exactly correct :).</div><div class=""><br class=""></div><div class="">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.</div><div class="">&nbsp;<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto" class=""><div class=""><span class=""><br class=""><blockquote type="cite" class=""><div class=""><div class=""><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div style="word-wrap:break-word" class=""><div class=""><div class=""><br class=""></div><div class="">// Module A</div><div class="">public struct S {</div><div class="">&nbsp; &nbsp; public typealias Foo = Int</div><div class="">}</div><div class=""><br class=""></div><div class="">// Module B</div><div class="">public protocol P {</div><div class="">&nbsp; &nbsp; associatedtype Foo</div><div class="">}</div><div class=""><br class=""></div><div class="">// Module C</div><div class="">import A</div><div class="">import B</div><div class=""><br class=""></div><div class="">// compiler error: `S` does not meet the `Foo` associatedtype requirement</div><div class="">extension S : P {</div><div class="">&nbsp; &nbsp; // compiler error: cannot define associatedtype `Foo` for `S` which already declares typealias `Foo`</div><div class="">&nbsp; &nbsp; associatedtype Foo = String</div><div class="">}</div><div class=""><br class=""></div><div class="">I cannot support any proposal that breaks retroactive modeling in this way.</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">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.</div></div></div></blockquote><div class=""><br class=""></div></span><div class="">Did you mean conforming a type to two protocols with an 'Element' associatedtype?</div><div class=""><br class=""></div><div class="">I consider that issue to be in the realm of multiple conformances rather than retroactive modeling.&nbsp; I can still&nbsp;</div></div></div></blockquote><div class=""><br class=""></div><div class="">Yeah, I completely mangled that sentence.</div><div class=""><br class=""></div><div class="">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.</div></div></div></div></div></blockquote><div><br class=""></div><div>I suppose you can look at it that way. &nbsp;</div><div><br class=""></div><div>Here’s a suggestion for your proposal: if we’re going to go as far as requiring explicit `associatedtype` declarations why not allow disambiguation? &nbsp;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. &nbsp;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.</div><div><br class=""></div><div>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).&nbsp;</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">&nbsp;</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto" class=""><div class=""><span class=""><br class=""></span></div><div class=""><span class=""><div class=""><br class=""></div></span><div class="">Thank you for adding the clarifications.&nbsp; I feel a little better knowing we wouldn't lose expressive power, but still prefer the directed inference suggested by Dmitri.</div><div class=""><div class="h5"><br class=""></div></div></div></div></blockquote><div class=""><br class=""></div><div class="">And thank you for your honest feedback!&nbsp;</div></div><br class=""></div></div>
</div></blockquote><br class=""></div><div>You’re welcome. &nbsp;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. &nbsp;In the end I trust the core team will make the right decision. &nbsp;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.</div><div><br class=""></div><div>-Matthew</div><br class=""></body></html>