[swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>
Austin Zheng
austinzheng at gmail.com
Sat May 14 13:35:24 CDT 2016
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>
More information about the swift-evolution
mailing list