> On Aug 17, 2016, at 12:02 PM, Vladimir.S via swift-evolution 
> <[email protected]> wrote:
> 
> On 17.08.2016 13:00, Boris Wang via swift-evolution wrote:
>> The problem is that:
>> protocol should not be a type, but it is a type sometime and not type
>> sometime now.
>> 
>> for exam:
>> P.Type not same as T.Type
>> 
>> But you can declare a variable of type P.
>> 
>> Protocol should be a contract only, no instances of it.
> 
> I'm also confused about this. Tried to follow the whole discussion of 
> experienced(as I understand) developer Charles and a member of core team, and 
> saw that even experienced developer had some troubles to understand all the 
> catches of protocols in Swift.
> 
> How we want to make less experienced developers to understand Swift's model 
> of protocols&conformance&generic&existentials&etc.. While problems begins 
> with the most used Equatable/Hashable protocols..
> 
> Also I believe the syntax of generic constraints in 'where' part is 
> confusing. I'm about this:
> 
> func pick<PepperType:Sequence>(peppers: PepperType) where 
> PepperType.Iterator.Element == Pepper
> 
> If '== Proto' means *exactly* typed as such protocol("let arr : [Proto] = 
> .."), so IMO ': Proto' should means *typed* as exactly this protocol or any 
> derived protocol("let arr : [ProtocolDerivedFromProto] = .."). Just in 
> symmetry with class types in 'where' clause here.
> 
> Currently, how to specify 'protocol Proto or its derived protocols" ?

Basically, the issue is that as things currently stand, there is no way to 
specify that. Your options basically boil down to: 1) implement the method 
twice, 2) force the caller to cast to the protocol first, or 3) just use an 
array.

> I suggest to discuss changing the rules for 'where' generic filter for 
> protocols:
> 
> 1. Don't allow syntax ': P' or '== P' for protocols. Such syntax should be 
> allowed only for classes, structs & other value types.
> 
> 2. For protocol introduce 'is P' syntax, which should mean 'typed exactly as 
> P, or its derived protocol, or as concrete type conformed to P'. I.e.:
> 
> func pick<PepperType:Sequence>(peppers: PepperType) where 
> PepperType.Iterator.Element is Pepper
> 
> 3. If it is hard to implement (2) today in the "right" way, implement it with 
> two copies of the same function, one with ":P" and one with "==P"(was 
> discussed earlier in thread)

This looks identical to my pitch, only with the operator named “is” instead of 
“:==“. Unfortunately, we now have Word of God that the Swift team wants to 
avoid cloning functions à la C++ templates, so it may be a bit of a non-starter.

Charles

_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to