For every Bar.T that is currently distinct from Foo.T, this would be source-breaking.<br><div class="gmail_quote"><div dir="ltr">On Sat, Jun 24, 2017 at 01:51 David Sweeris via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> On Jun 23, 2017, at 5:28 PM, David Moore via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
><br>
> I do indeed have quite a few real examples of this, such prompted me to bring this up. I think this could be done without any impact to existing code, but it would require some type of keyword. Take the following as a possible prototype.<br>
><br>
> protocol Foo {<br>
> associatedtype T<br>
> }<br>
><br>
> struct Bar<T> : Foo {<br>
> keyword typealias T // Or really any other syntactical implementation.<br>
> }<br>
><br>
> With an opt-in method we could implement this without affecting existing code, thereby making this more viable. I will send some examples later.<br>
<br>
At one point there was talk of just having generic parameters automatically becoming typealiases:<br>
struct Bar<T> : Foo {<br>
// `T` is automatically an implicit typealias for, well, `T`<br>
}<br>
<br>
Dunno if that’s still the plan (or to what degree it ever was), but it’d work for me. I don’t even think it’d break source compatibility (though it may make a lot of typealiases unneeded.<br>
<br>
- Dave Sweeris<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div>