[swift-evolution] [Discussion] Generic protocols

[Xiaodi Wu]

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.c
>> 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 (
>>> 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/81791e92/attachment.html>