Would that even compile? I thought I'd remembered getting an "illegal redefinition of T" or some such error, but maybe I'm misremembering (plus, I haven't tried in a really long time).
- Dave Sweeris > On Jun 24, 2017, at 08:48, Xiaodi Wu <[email protected]> wrote: > > 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
