[swift-evolution] [Discussion] Generic protocols

[Anton Zhilin]

2016-12-10 14:57 GMT+03:00 Adrian Zubarev <adrian.zubarev at devandartist.com>:

I’m fine with adding features step by step. ;)
>
> There is no need for an explicit type alias in your
>
> extension MyStruct : Constructible<String> { … }
>
> Because Value is already constrained by String.
>
That was my proposed syntax for inline conversion of associated-types
protocols to generics. In this case, implicit or explicit, this typealias
would appear in MyStruct.

In my typealias examples I mixed *1.* and *4.* together.
>
> protocol GenericFoo<T> : Foo where Value == T { /* nothing here */ }
>
> typealias GenericFoo<T> = Foo where Value == T
>
> I see that the latter cannot produce an actual new protocol, because it’s
> more like a macro and cannot be used multiple times for conformances.
>
> struct D : GenericFoo<Int>, GenericFoo<String> {}
>
> // vs.
> struct D : Foo where Value == Int, /* cannot add the second macro for String */ {}
>
> And that is probably why we need real parametrized protocols.
>
That was not an unsolvable problem, but I guess, parametrized protocols is
the first feature to consider.

Questions about *1.*:
>
>    - Does it affect ABI or is it needed to simplify the stdlib somehow?
>    - Is it something for the current phase?
>
> I found that the only protocol family that looks like it could be replaced
by a generic protocol, is ExpressibleBy* protocols.
But on a closer look, each of them has its own nuances, which prevents us
from using a single LiteralConvertible<T> instead.

So I guess, no existing ABI would need changes, and stdlib is not affected.
So probably it’s not for current phase?
I really wish I’m wrong here.
​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161211/3af60ba8/attachment.html>