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

[Xiaodi Wu]

On Sat, Jun 24, 2017 at 12:09 PM, David Sweeris <davesweeris at mac.com> wrote:

> 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).
>

There is no redefinition; it's just simple shadowing.

```
protocol P {
  associatedtype T
  func foo() -> T
}

struct S<T> : P {
  func foo() -> Int {
    return 42
  }
  func bar(_ x: T) -> T {
    return x
  }
}

S<String>().foo() // P.T is Int
S<String>().bar("42") // S.T is String
```

- 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/4c1dc9c4/attachment.html>