[swift-evolution] Partially Constrained Protocols [Was: [Proposal] Separate protocols and interfaces]

[David Waite]

I did think of an additional type constraint needed now due to the additional flexibility in the proposed type system.

Today, The != operator might be defined as follows

func !=<T:Equatable>(lhs:T, rhs:T) -> Bool {
    return !(lhs==rhs)
}

Since the only way today for there to be a reference to something equatable is for you to have a concrete implementing type, this will get the appropriate view of Equatable (e.g. can see the ==(_:Self,_:Self)->Bool method)

However, since the type system has expanded to now allow references to partially constrained protocols, the above is insufficient to provide access to the == operator. Example:

let x:Hashable = "Foo"
let y:Hashable = "Bar"

x != y // Not defined, since there is no ==(_:Hashable, _:Hashable)->Bool

We need a way to differentiate when we are trying to statically require a concrete type. One could reuse one of the existing keywords or an operator, but for now I’ll expand my placeholder syntax with a placeholder keyword, “concrete”

func !=<concrete T:Equatable>(lhs:T, rhs:T) -> Bool {

or from the SequenceType version I posted yesterday:

> extension SequenceType where concrete Element:Equatable {
>     func elementsEqual<OtherSequence : protocol<SequenceType where .Element == Element>(other: OtherSequence) -> Bool
>     func split(separator: Element, maxSplit: Int, allowEmptySlices: Bool) -> [protocol<SequenceType where .Element == Element>]
>     func startsWith(other: protocol<SequenceType where .Element == Element) -> Bool
> }

(Another option for a new syntax would be to require explicit syntax for using Equatable as a existential type - i’m deferring that until there is more successful discussion on the ideas themselves.)

-DW
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160119/0aadf493/attachment.html>