This might become possible if we eventually allowed an existential to conform
to its containing protocol (forgive the strawman syntax):
extension Any<Equatable> : Equatable { }
func =(lhs: Any<Equatable>, rhs: Any<Equatable>) -> Bool {
if let rhs = rhs as? lhs.Self {
// Open the existential type to check for type equality
return lhs == rhs
}
return false
}
// Something like "Any<Equatable, Fooable>" would be a subtype of
"Any<Equatable>" and benefit from the conformance.
There would be a family of protocols for which we'd be able to define
homogenous conformance (e.g. homogenous equality) on specific types, and
heterogeneous conformance across the existential satisfying all the specific
types.
That being said, it's not clear whether or not it would be possible to
generalize this to protocols with associated type constraints, not just `Self`
constraints...
Austin
> On Jun 29, 2016, at 12:46 AM, Robert Widmann via swift-evolution
> <[email protected]> wrote:
>
> This is what I mean by diluting the semantics of these protocols. A type is
> not universally equatable, it is equatable with respect to values of its same
> type. Adding a generic is precisely an encoding of the former (even if this
> particular implementation says otherwise), our current implementation is an
> encoding of the latter. If you want to fix this, ask yourself: How is the
> typechecker supposed to know that you mean to include this extra "self-ness"
> constraint when you write e.g. Set<Equatable>?
>
> As David mentioned, you may get some mileage out of existentials, but really
> only if you have a class hierarchy [Equatability will still come with
> constraints, even then]. You are absolutely right that your use-case is
> valid and I regret that you have to jump through hoops to ask for something
> that can be expressed so cleanly in the hypothetical. But until we have
> inference rules and/or syntax for this it's all just that.
>
> ~Robert Widmann
>
> 2016/06/29 0:05、Riley Testut <[email protected]
> <mailto:[email protected]>> のメッセージ:
>
>> I do appreciate the thought out reply Robert! First, I do realize there are
>> reasons *why* this is the case, my point is that we should re-evalutate
>> these implementations so they’re no longer a reason :)
>>
>> Secondly, for the Equatable protocol, I see two possible solutions. One
>> would be to simply treat two types that do not belong to the same
>> inheritance hierarchy as not equal (and is the approach I’ve taken in my own
>> code). Here is a simplified example taken from my current project:
>>
>> public protocol InputProtocol
>> {
>> /// Convenience method used for implementing Equatable. Default
>> implementation via protocol extension
>> func isEqual<T>(_ input: T) -> Bool
>> }
>>
>> /// Provide default implementatation for InputProtocol.isEqual()
>> public extension InputProtocol where Self: Hashable
>> {
>> func isEqual<T>(_ input: T) -> Bool
>> {
>> if let input = input as? Self
>> {
>> return self == input
>> }
>>
>> return false
>> }
>> }
>>
>> Now, I can compare any two InputProtocol types using the generic isEqual()
>> method and it will do The Right Thing. However, an alternative approach is
>> to simply be able to declare a == overload for a certain protocol like so:
>>
>> protocol MyProtocol
>> {
>> var identifier: UUID { get }
>> }
>>
>> func ==(lhs: MyProtocol, rhs: MyProtocol) -> Bool { return lhs.identifier ==
>> rhs.identifier }
>>
>> The only downside to this method I see is that it could potentially be
>> abused in a way to make two types that seemingly shouldn’t be equatable
>> return true, such as conforming Int and String to MyProtocol above and both
>> having the same identifier. Not sure how bad this would be in actual
>> practice though (as in whether this would end up being a problem).
>>
>> As for my specific use case, I’m developing a very modular, plug-in based
>> application. Necessarily each plug-in effectively declares it’s own
>> implementation of certain protocols, so unfortunately there’s no way to
>> guarantee the application knows about all possible implementations at
>> compile time.
>>
>>> On Jun 29, 2016, at 1:49 AM, Robert Widmann <[email protected]
>>> <mailto:[email protected]>> wrote:
>>>
>>> Yes, the restriction "sucks", but it is there for a reason. A protocol is
>>> not just a convenient collection of methods and properties you can
>>> generalize over, it's a contract. Each tells you something about what its
>>> implementers have to do before they can call themselves 'Equatable' or
>>> 'MyProtocol' etc. Let's see what happens at a very high level if we relax
>>> this constraint for Equatable as you have written here.
>>>
>>> protocol Equatable {
>>> func ==(_: Equatable, _: Equatable) -> Bool
>>> }
>>>
>>> And now two implementers (implementation abbreviated for brevity)
>>>
>>> extension String: Equatable {}
>>> extension Int: Equatable {}
>>>
>>> // ...
>>>
>>> Given this definition, the following typecheck
>>>
>>> 1 == 2 // false
>>> "A" == "A" // true
>>> 1 == "1" // ?
>>> "ABC" == 123 // ?
>>>
>>> Being Equatable suddenly must include a component of self-identity. We
>>> have to be able to constrain the implementation to only those Equatable
>>> things that look like ourselves. Thus, Self constraints. Because
>>> 'MyProtocol' is not defining a protocol for things that understand
>>> equality, it is defining an equivalence relation over all possible
>>> implementations of ==, and that means that anything goes.
>>>
>>> So you might modify this to use associated types then. What about an
>>> iteration that asks the implementer to specify the type made in the
>>> comparison?
>>>
>>> protocol Equatable {
>>> associatedtype Comparator
>>> func ==(_: Equatable.Comparator, _: Equatable.Comparator) -> Bool
>>> }
>>>
>>> This also solves nothing. You can't actually constrain the associated
>>> types here with a needed equality constraint. You can only push the
>>> problem down a needless level of abstraction.
>>>
>>> Yes it's a pain to have to use Generics to reify restricted protocols. Yes
>>> it's a pain to give up use of protocol-ified collections. Yes it's not
>>> immediately obvious why these restrictions are in place. But to drop them
>>> would severely dilute the intended semantics and use of protocols that
>>> require knowledge of their reifications. Unfortunately, equality just
>>> happens to be one such protocol.
>>>
>>> There are ways around this. If you have a sealed hierarchy you can write
>>> an enum that enumerates all possible implementations and delegates it's
>>> equatable conformance out to them. Often, identity can be found elsewhere
>>> in a type. For example, a hypothetical 'UUIDable' protocol could specify
>>> it's implementers produce a String UUID that could be stored in collections
>>> instead of UUIDable types themselves. For most other cases try to
>>> re-evaluate. Why do you need to generalize over this set of types in this
>>> way? Is there some other more generic way of handling this case?
>>>
>>> ~Robert Widmann
>>>
>>> 2016/06/28 23:17、Riley Testut via swift-evolution
>>> <[email protected] <mailto:[email protected]>> のメッセージ:
>>>
>>>> Hello all,
>>>>
>>>> If you’ve been (attempting) protocol-oriented development in your own
>>>> projects, I’m sure you’ve come across a particular build error at one
>>>> point:
>>>>
>>>>> Protocol ‘MyProtocol' can only be used as a generic constraint because it
>>>>> has Self or associated type requirements
>>>>
>>>> To be frank, this restriction in the current Swift model sucks, a lot. In
>>>> *many* cases, this prevents me from using protocols, and instead I have to
>>>> fall back to using concrete types.
>>>>
>>>> Here are a couple examples of using protocols with collections that should
>>>> work fine, but simply don’t:
>>>>
>>>> A Set of Types Conforming to Protocol
>>>>
>>>> protocol MyProtocol: Hashable {}
>>>>
>>>> let set = Set<MyProtocol>() // ERROR: Protocol ‘MyProtocol' can only be
>>>> used as a generic constraint because it has Self or associated type
>>>> requirements
>>>>
>>>> When declaring a Set, the generic type of the Set’s contents must conform
>>>> to Hashable. Following this, it would appear that you should be able to
>>>> declare a Set containing types conforming to a given protocol which in
>>>> turn conforms to Hashable. Nope! This also means you can’t have a
>>>> Set<Hashable> (so no type-erased Sets for you!). One potential workaround
>>>> is to use a box type, but if exposing the set to a user, this is
>>>> essentially a leaky abstraction.
>>>>
>>>> Finding a Protocol Type Instance in an Array
>>>>
>>>> protocol MyProtocol {}
>>>> struct MyStruct: MyProtocol {}
>>>>
>>>> var array = [MyProtocol]()
>>>> array.append(MyStruct())
>>>>
>>>> let index = array.index(of: MyStruct()) // ERROR: Cannot invoke 'index'
>>>> with an argument list of type '(of: MyStruct)'
>>>>
>>>> So, we can’t use Set as a collection for our protocol types, let’s use
>>>> Array instead! Not so fast: because MyProtocol doesn’t conform to
>>>> Equatable, we can’t use the Array.index(of:) function to find it. Easy fix
>>>> though, just make MyProtocol conform to Equatable, right?
>>>>
>>>> protocol MyProtocol: Equatable {}
>>>> struct MyStruct: MyProtocol {}
>>>>
>>>> var array = [MyProtocol]() // ERROR: Protocol ‘MyProtocol' can only be
>>>> used as a generic constraint because it has Self or associated type
>>>> requirements
>>>>
>>>> Nope! Now that it conforms to Equatable, it can no longer be used in
>>>> Array’s type declaration. However, there is a (somewhat) workaround for
>>>> this problem:
>>>>
>>>> protocol MyProtocol {}
>>>> func ==(lhs: MyProtocol, rhs: MyProtocol) -> Bool { return true }
>>>>
>>>> struct MyStruct: MyProtocol {}
>>>>
>>>> var array = [MyProtocol]()
>>>> array.append(MyStruct())
>>>>
>>>> let index = array.index(where: { $0 == MyStruct() })
>>>>
>>>> Basically, we can define the == function for MyProtocol, and then instead
>>>> of using Array.index(of:), we use Array.index(where:) to manually compare
>>>> each item to see if it matches, aka what Array.index(of:) would do for us
>>>> normally if we simply could declare MyProtocol as conforming to equatable.
>>>>
>>>> TL;DR
>>>> Swift really pushes the idea of protocol-oriented programming, and for the
>>>> most part this works well. However, due to some underlying restrictions in
>>>> the current Swift model, you can’t use protocols in all the same places
>>>> you can use concrete types, which sucks. This is especially confusing for
>>>> beginners who are trying to use protocols, but get frustrated when it
>>>> doesn’t work where they want it to (and don’t understand why), so they
>>>> fall back to using concrete types (usually implemented with class
>>>> inheritance). For this reason, I think these restrictions need to be fixed
>>>> ASAP, or else the Swift language is essentially pushing people away from
>>>> protocol-oriented programming.
>>>>
>>>> Riley Testut
>>>>
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> [email protected] <mailto:[email protected]>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
