[swift-evolution] [Proposal] Associated Type and Generic One-to-One Mapping

[David Sweeris]

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 <xiaodi.wu at gmail.com> 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 <swift-evolution at swift.org> wrote:
>> 
>> > On Jun 23, 2017, at 5:28 PM, David Moore via swift-evolution <swift-evolution at swift.org> 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
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170624/fa2ab339/attachment.html>