protocol Foo { associatetype Inner : SomeOtherProtocol } // Assuming String and Int conforms to SomeOtherProtocol protocol StringFoo : Foo where Inner == String {} protocol IntFoo : Foo where Inner == Int {} On Sat, Dec 3, 2016 at 13:57 Adrian Zubarev <adrian.zuba...@devandartist.com> wrote:
> To which code ‘above’ do you refer exactly? > > > > -- > Adrian Zubarev > Sent with Airmail > > Am 3. Dezember 2016 um 20:29:05, Xiaodi Wu (xiaodi...@gmail.com) schrieb: > > On Sat, Dec 3, 2016 at 12:02 PM, Daniel Leping via swift-evolution < > swift-evolution@swift.org> wrote: > > @Adrian, my comments inline below. Hope this helps. > > On Sat, Dec 3, 2016 at 6:22 PM, Adrian Zubarev < > adrian.zuba...@devandartist.com> wrote: > > There is one thing that I want to point out with pitched syntactic sugar. > GenericMyProtocolName<U> will also let you reuse T within a generic type, > where currently we cannot nest protocols into types. Even if we could, it’s > not clear if nested declarations like protocol MyTProtocolName : > MyProtocolName where U == T would be possible, so that T from the outer > generic type is accessible. > > Autogenerating the only possible generic protocols from protocols with > associated types as a syntactic sugar to reduce spawning of types like > IntFoo (as previously showed) seems reasonable to me. It does not break > the current protocol system, but solves the first generic protocol feature > from the generics manifesto. > > There are still a few more questioned to answer: > > - How dow we want the generated parameter list to look like? > > The most obvious thing is to do something like Foo<Alias1 = Int, Alias2 = > String>. Otherwise we'll have to add some sort of associatedtype sorting > before; which doesn't sound good and just adds more complexity. Any other > options? > > > - Can we drop Generic prefix without collisions? > > I'm pretty sure we could just use existing protocols. All the namings can > be compiler generated as a function from protocol and arguments. > > > - Does this syntactic sugar improves the stdlib or affect ABI? > > Don't see any implications. Assuming current stdlib doesn't use the > feature. It's rather an addition than change. > > There are probably some more questions I cannot foresee by myself. Feel > free to jump in the discussion. ;) > > PS: Yes this syntactic sugar does create an alternative way of creating > ‘kinda’ the same protocol twice, but it reuses the pattern more naturally. > > protocol Foo { associatetype Inner : SomeOtherProtocol } > > // Assuming String and Int conforms to SomeOtherProtocol > protocol StringFoo : Foo where Inner == String {} > protocol IntFoo : Foo where Inner == Int {} > > > I thought I understood the initial topic of discussion, but I am lost > here. What is unsatisfactory about the code you wrote above and why do we > need new sugar for it? > > > // VS. > > // autogenerated > procotol GenericFoo<Inner : SomeOtherProtocol> : Foo { … } > > // usage > GenericFoo<String> > GenericFoo<Int> > > // or > typealias StringFoo = GenericFoo<String> > typealias IntFoo = GenericFoo<Int> > > // The usage I propose is just do > typealias StringFoo = Foo<Inner = String> > > //also in an inheritance like this: > class FooClass : Foo<Inner = String>, Foo<Inner = Int> { > //My question here is, though: how do we access Inner from FooClass > > //Like this? > typealias InnerInt = Foo<Inner = String>.Inner > } > > > > -- > Adrian Zubarev > Sent with Airmail > > Am 3. Dezember 2016 um 16:43:43, Daniel Leping (dan...@crossroadlabs.xyz) > schrieb: > > In general I'm very positive with the idea of generic protocols. This > discussion is more about syntactic sugar, though I really like where it > goes. > > Off topic: > IMO, we should revisit approaches others already use for conflicts > resolution. I personally tend to get something similar to Scala traits. > Should fit POT smoothly and naturally. > > On Sat, 3 Dec 2016 at 16:30 Adrian Zubarev < > adrian.zuba...@devandartist.com> wrote: > > If I’m not mistaken here, extension Foo where T == Int will have an error > of redeclaration foo anyways. > > > -- > Adrian Zubarev > Sent with Airmail > > Am 3. Dezember 2016 um 15:22:56, Adrian Zubarev ( > adrian.zuba...@devandartist.com) schrieb: > > extension Foo where T == Int { > func foo() { > self.bar(o: 42) // calls a function that accepts an Int > } > } > > > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution > > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution