<div dir="ltr">Inline<br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 27, 2016 at 6:47 AM, Matthew Johnson <span dir="ltr">&lt;<a href="mailto:matthew@anandabits.com" target="_blank">matthew@anandabits.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div><br><br>Sent from my iPad</div><span class=""><div><br>On Jun 25, 2016, at 12:41 PM, Austin Zheng &lt;<a href="mailto:austinzheng@gmail.com" target="_blank">austinzheng@gmail.com</a>&gt; wrote:</div></span><span class=""><blockquote type="cite"><div><div><div>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><br></div></span>IIUC you&#39;re saying a type is allowed to have an <span style="background-color:rgba(255,255,255,0)">`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.</span></div></blockquote><div><br></div><div>Yes, that is exactly correct :).</div><div><br></div><div>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&#39;s there in case the core team disagrees.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div><span class=""><br><blockquote type="cite"><div><div><div><br></div><blockquote type="cite"><div><div style="word-wrap:break-word"><div><div><br></div><div>// Module A</div><div>public struct S {</div><div>    public typealias Foo = Int</div><div>}</div><div><br></div><div>// Module B</div><div>public protocol P {</div><div>    associatedtype Foo</div><div>}</div><div><br></div><div>// Module C</div><div>import A</div><div>import B</div><div><br></div><div>// compiler error: `S` does not meet the `Foo` associatedtype requirement</div><div>extension S : P {</div><div>    // compiler error: cannot define associatedtype `Foo` for `S` which already declares typealias `Foo`</div><div>    associatedtype Foo = String</div><div>}</div><div><br></div><div>I cannot support any proposal that breaks retroactive modeling in this way.</div></div></div></div></blockquote><div><br></div><div>Addendum aside, retroactive modeling is already suboptimal or broken in multiple ways today - try conforming a protocol with associated type &#39;Element&#39; to a different protocol whose &#39;Element&#39; means something completely different.</div></div></div></blockquote><div><br></div></span><div>Did you mean conforming a type to two protocols with an &#39;Element&#39; associatedtype?</div><div><br></div><div>I consider that issue to be in the realm of multiple conformances rather than retroactive modeling.  I can still </div></div></div></blockquote><div><br></div><div>Yeah, I completely mangled that sentence.</div><div><br></div><div>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><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div><span class=""><br></span></div><div><span class=""><div><br></div></span><div>Thank you for adding the clarifications.  I feel a little better knowing we wouldn&#39;t lose expressive power, but still prefer the directed inference suggested by Dmitri.</div><div><div class="h5"><br></div></div></div></div></blockquote><div><br></div><div>And thank you for your honest feedback! </div></div><br></div></div>