Protocol conformance with constraints

I think the following is a sensible concept:


protocol SpecialValue {}
extension Array: SpecialValue where Element: SpecialValue { }


(that is, an array of SpecialValues is also a SpecialValue), but the above crashes both SourceKit and the Swift 2 compiler.


Even this less specific version crashes both SourceKit and the compiler:


extension Array where Element: SpecialValue { }


Are either of these supposed to be something that can be wriiten in Swift? The similar:


extension CollectionType where Generator.Element: SpecialValue { }


works, but this:


extension CollectionType: SpecialValue where Generator.Element: SpecialValue { }


produces an error "Extension of protocol 'CollectionType' cannot have an inheritance clause".

I cannot follow that you are trying to do. I believe 1. protocols should be adjectives for all generic examples, and 2. you are conflating two concepts.

Well, you can call it SpecialValueType if you want — that's an acceptable alternative to an adjective in Swift 2's ecosystem, I think.


What concepts am I conflating? What I'm trying to say is the analogy of saying that a NSArray of NSObjects is a NSObject, which is what (in Obj-C) allows a NSArray to occur inside another NSArray.

I think what the OP means is approximately the same as what is talked about here:

https://forums.developer.apple.com/message/16869

and here:

https://forums.developer.apple.com/message/20294

Oh, okay! You're talking about

extension [Special]: Special {}


C# has had that since before some of us were, but not in terms of conformance. Just extension methods:

public static void SpecialMethod(this IEnumerable<Special> source) {}


Of course, Swift's use of typealiases for protocols, instead of angle brackets for generics, makes the concept nigh untypeable, for collection protocols that don't have syntactic sugar. It's time to do away with the typealiases perhaps; have they yielded a purpose?

Jessy >> Oh, okay! You're talking about extension [Special]: Special {}


Yes, but that doesn't compile either. You get the same message as you do for Array<Special> — "remove the type specializer and use a where clause instead". And then we're back at door #1.


Jens: I think what the OP means is approximately the same as what is talked about here:


Yes, though it's mostly about Equatable (which I would need my protocol to conform to, I see now), but no one seems to have an answer about why conformance and constraints can't be specified together.


In regard to Equatable, why is [AnyObject] legal, since AFAICT AnyObject doesn't conform to Equatable?

I knew it wouldn't compile yet; that's why I gave the example of how it works elsewhere. I assume that the problem is just that the people who made Swift didn't have enough time to use C# enough, to learn all of the features that they should have taken from it, and that they need us to tell them about the important stuff they missed. It's intriguing, the amount of comparisons Swift has had to won't-touch-Microsoft-with-a-Grinch-pole languages, when it's much closer to being C#.

Anyone know if there's any new information on this? Like OP I need to add conformance to Collections of conforming types:


protocol Parameter {
...
}

extension String: Parameter {
...
}

// Lots more conforming types


Then something like:


extension CollectionType where Generator.Element == Parameter : Paraemter {
...
}


So that I can pass either 'String' or '[String]' to a function expecting 'Parameter'.

Protocol conformance with constraints
 
 
Q