[swift-evolution] [Discussion] Generic protocols

[Xiaodi Wu]

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.zubarev at 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.wu at gmail.com) schrieb:
>
> On Sat, Dec 3, 2016 at 12:02 PM, Daniel Leping via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> @Adrian, my comments inline below. Hope this helps.
>
> On Sat, Dec 3, 2016 at 6:22 PM, Adrian Zubarev <
> adrian.zubarev at 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 (daniel at 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.zubarev at 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.zubarev at 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 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/20161203/8ab545ad/attachment.html>