protocol can only be used as a generic constraint because it has Self or associated type requirements

Exactly. This would let us write a function like

    func hash(Hashable... values) -> Int {
        // calculate combined hashValue from all hashable values
    }

analogous to Guava's Objects.hashCode to help implement hashValue in
custom structs.

Martin

···

On 14 December 2015 at 14:20, Marc Knaup via swift-evolution <swift-evolution@swift.org> wrote:

I find the suggestion from Paul Cantrell very useful where you can use all properties and methods of the protocol which do not depend on an associated type or Self.

var array = [Hashable]()
// …
for element in array {
    print(element.hashValue)
}

Who cares that it doesn't fulfill Equatable conformance yet?

Then you have the “P doesn’t conform to P” problem, which is too crazy to live. A recent internal discussion led to the idea that we should have notation for the existentially-viable subset of a protocol, so you could always make Array<existential P> but not necessarily Array<P> for an arbitrary protocol P. Just one way to address this use-case, of course.

-Dave

···

On Dec 15, 2015, at 10:02 AM, Thorsten Seitz <tseitz42@icloud.com> wrote:

Shouldn’t we just narrow the type of protocols with associated types and/or Self types when the protocol is used as a type?

Shouldn’t we just narrow the type of protocols with associated types and/or Self types when the protocol is used as a type?

<snip>

foo.value = x // ERROR: calling setter not allowed
foo.bar(x) // ERROR: not allowed
let z: Bounds = foo.baz(x) // ERROR: not allowed

The problem is that you are implicitly defining a fixed type protocol off of your “deferred type” protocol, but the designer of the protocol may have not understood the restrictions of use that will come from those using the implicit fixed-type protocol. By having this narrowed version of the protocol, you may be using the protocol “out of warranty”, e.g. in a way that the original designer never intended.

I’ve spent significant time refactoring code after the fact which has had similar behavior by using wildcards. Java makes this worse by having unreified generics, which may result in the problem being deferred until someone actually pays attention that the type system is fundamentally inconsistent.

Still, I feel anything that defers the fixed type protocol design from being considered as part of the API design of the protocol is penalizing the users of the library, not the creator. Without fixing the protocol, my only choice with the above code is to switch to using generic constraints, potentially “all the way up”

-DW

···

On Dec 15, 2015, at 11:02 AM, Thorsten Seitz via swift-evolution <swift-evolution@swift.org> wrote:

Making this narrowing explicit is a good idea!

-Thorsten

···

Am 16.12.2015 um 02:06 schrieb Dave Abrahams <dabrahams@apple.com>:

On Dec 15, 2015, at 10:02 AM, Thorsten Seitz <tseitz42@icloud.com> wrote:

Shouldn’t we just narrow the type of protocols with associated types and/or Self types when the protocol is used as a type?

Then you have the “P doesn’t conform to P” problem, which is too crazy to live. A recent internal discussion led to the idea that we should have notation for the existentially-viable subset of a protocol, so you could always make Array<existential P> but not necessarily Array<P> for an arbitrary protocol P.