[swift-evolution] [Discussion] Generic protocols

[Daniel Leping]

@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 {}
>
> // 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
>>      }
>> }
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161203/c7a2fc8c/attachment.html>