[swift-evolution] protocol can only be used as a generic constraint because it has Self or associated type requirements

[David Waite]

> On Dec 15, 2015, at 11:02 AM, Thorsten Seitz via swift-evolution <swift-evolution at swift.org> 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?
> 
> 
<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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151215/f067ce18/attachment.html>