[swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

[Vladimir.S]

On 14.05.2016 21:20, Austin Zheng wrote:
> Yes, this is theoretically possible, but why is it useful? (I am genuinely
> curious.)

I just showing that we *can* invent the situation when checking for 
struct<Struct,Protocol> have a sense. Not more, not less.
I'm not going to discuss if that can have any (or never can have at all) 
useful intention.

>
> If the intention is to allow B to be a user-defined extension point for T,
> this goes back to the core team's arguments (in the thread about optional
> protocol requirements) about why having checking for conformance to some
> requirement at the use site is a suboptimal idea.
>
> If the intention is to make the type system as expressive as possible, the
> core team has already ruled out a number of features (user-defined variance
> on generics, generic protocols) because they don't believe in their general
> applicability.
>
> Austin
>
> On Sat, May 14, 2016 at 11:13 AM, Vladimir.S <svabox at gmail.com
> <mailto:svabox at gmail.com>> wrote:
>
>     FWIW, yes, protocols available for struct are known at compile-time,
>     but could be unknown at the *moment of writing* the code.
>
>     What I mean:
>
>     Step 1. I write source code:
>
>     protocol A {}
>     protocol B {}
>     struct S:A {}
>
>     func f(a: A) {
>       if a is struct<S,B> {...} // I expect that S could be conformed to B
>     }
>
>     Step 2. I give my code to someone, who can do somewhere in his project:
>
>     extension S:B{..}
>
>
>
>
>     On 14.05.2016 7:06, Austin Zheng via swift-evolution wrote:
>
>         1. struct<SomeConcreteStruct, Protocol1, Protocol2>. In this case the
>         struct<...> representation is unnecessary; the protocols that are
>         available
>         to the user are known at compile-time, and structs can't have
>         subtypes that
>         conform to additional protocols like classes can. There is an example
>         marked "func boo(value: struct<SomeStruct>) /* equivalent to */ func
>         boo(value: SomeStruct)"; my question is why having more than two
>         ways to
>         express the same idea makes the language better, easier to use, etc.
>
>