[swift-evolution] [Proposal] Associated Type and Generic One-to-One Mapping
Xiaodi Wu
xiaodi.wu at gmail.com
Sat Jun 24 10:48:57 CDT 2017
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/96c68566/attachment.html>
More information about the swift-evolution
mailing list