For every Bar.T that is currently distinct from Foo.T, this would be source-breaking. On Sat, Jun 24, 2017 at 01:51 David Sweeris via swift-evolution < [email protected]> wrote:
> > > On Jun 23, 2017, at 5:28 PM, David Moore via swift-evolution < > [email protected]> wrote: > > > > 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. > > > > protocol Foo { > > associatedtype T > > } > > > > struct Bar<T> : Foo { > > keyword typealias T // Or really any other syntactical > implementation. > > } > > > > With an opt-in method we could implement this without affecting existing > code, thereby making this more viable. I will send some examples later. > > At one point there was talk of just having generic parameters > automatically becoming typealiases: > struct Bar<T> : Foo { > // `T` is automatically an implicit typealias for, well, `T` > } > > 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. > > - Dave Sweeris > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
