[swift-evolution] [Discussion] Generic protocols

Sat Dec 3 14:21:11 CST 2016

I'm not sure I understand. The first feature in the generics manifesto is
parameterized protocols so that you can have, say, ConstructibleFrom<Float>
and ConstructibleFrom<Int> and the ability to conform to the same protocol
in two ways. The second feature is explained as a request for generalized
existentials. I don't understand how syntactic sugar solves either issue.

I'm also not sure how your proposed "autogenerated" GenericFoo is more
"handy" than the code I asked about; it seems to use angle brackets instead
of the word where, but otherwise I don't see much of a difference. And the
generics manifesto writes that putting associated types in angle brackets
confuses them with true generic protocols and should be avoided. Can you
elaborate on what I'm not understanding?
On Sat, Dec 3, 2016 at 14:09 Adrian Zubarev <adrian.zubarev at devandartist.com>
wrote:

> Assume you’d need to create like 5–10 different sub-protocols where each
> of them has a unique type. We also let the new protocol unmodified, so that
> we only use the where clause from SE–0142 to specify all the associated
> types.
>
> protocol IntFoo : Foo where Inner = Int {}
> StringFoo
> DoubleFoo
> …
>
> Now for each type we need to repeat the same pattern all over again, just
> to specify all the associated types of Foo.
>
> Wouldn’t be handy to have autogenerated GenericFoo<Inner :
> SomeOtherProtocol> : Foo which will covert that for you.
>
> The only step you’d need to do is to pass a type you want to the parameter
> list.
>
> The generics manifesto explains two different features what generic
> protocols could do. That is exactly the first feature of these two, where
> the second requested feature from the generics manifesto is no go for
> Swifts generic system.
>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 3. Dezember 2016 um 20:58:52, Xiaodi Wu (xiaodi.wu at gmail.com) schrieb:
>
> 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/4d1c7d9d/attachment.html>