On Sat, Dec 3, 2016 at 12:02 PM, Daniel Leping via swift-evolution < [email protected]> wrote:
> @Adrian, my comments inline below. Hope this helps. > > On Sat, Dec 3, 2016 at 6:22 PM, Adrian Zubarev < > [email protected]> 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 ([email protected]) >> 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 <[email protected] >> om> 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 ( >>> [email protected]) schrieb: >>> >>> extension Foo where T == Int { >>> func foo() { >>> self.bar(o: 42) // calls a function that accepts an Int >>> } >>> } >>> >>> > > _______________________________________________ > 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
