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

[Austin Zheng]

That makes sense, thanks for pointing out a possibility I missed!

Austin

On Sat, May 14, 2016 at 11:34 AM, Vladimir.S <svabox at gmail.com> wrote:

> 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.
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160514/d4705934/attachment.html>