[SR-13502] Have to place empty generics when using protocol + where cause in function

[swift-ci]

Previous ID	SR-13502
Radar	rdar://problem/68376692
Original Reporter	mitchrobertson (JIRA User)
Type	Bug
Status	Resolved
Resolution	Duplicate

Environment

iOS/Mac

Additional Detail from JIRA

Votes	0
Component/s
Labels	Bug
Assignee	@slavapestov
Priority	Medium

md5: 41befb185230425037d83439a0756f21

relates to:

• [SR-4758] SE-0142: derived protocol that restricts associatedtype should be allowed as a variable type #47335

Issue Description:

If we create a simple protocol with a type condition like this:

protocol FloatSequence: IteratorProtocol, Sequence where Element == CGFloat {
    var count: Int { get }
    func reset()
}

If I do a global operator overload like this, I have to use empty generics to get it to compile.

func -<FS: FloatSequence>(left: FS, right: FS) -> CGFloat {
    // TODO
}

[typesanitizer]

@swift-ci create

[typesanitizer]

First problem is if I do a global operator overload like this, I have to use empty generics to get it compile.

I don't quite understand. What is the problem here? How would you prefer to write it instead?

Second problem, is if I want to add extensions to FloatSequence, I have to do this:

Again, I don't understand what exact issue you are facing here. The following code compiles fine:

protocol FloatSequence: IteratorProtocol, Sequence where Element == Float {}
extension FloatSequence {
  var element: Element { get { 0.0 } }
} 

This shows that the compiler already knows that Element == Float for FloatSequence so you don't need to specify it again.

[swift-ci]

Comment by Mitchell Robertson (JIRA)

You're right I was mistaken about the 2nd problem. Can I edit this bug to just refer to the first problem? I'd prefer to write:

func -(left: FloatSequence, right: FloatSequence) -> CGFloat { }

What is the point of forcing generics on this method with no `where` clause filter required?

[theblixguy]

func -(left: FloatSequence, right: FloatSequence) -> CGFloat {  }

The reason you can't write this is due to a language restriction i.e. protocols with associated types and non-covariant Self requirements aren't allowed to be used as existentials. There were technical reasons behind this restriction, but those have now been resolved and work is ongoing to lift it. You can read more about it here: https://forums.swift.org/t/lifting-the-self-or-associated-type-constraint-on-existentials/18025/

[swift-ci]

Comment by Mitchell Robertson (JIRA)

Thats excellent news - thankyou for your response. Should I close this or link to this issue?

[typesanitizer]

I'd prefer to write:

func -(left: FloatSequence, right: FloatSequence) -> CGFloat { }

There are two aspects to this:

1. As Suyash points out, there is a language restriction which stops you from creating existentials out of protocols with associated types and non-covariant Self requirements. This means you can't even write that signature.

2. An existential is not the same thing as a generic constraint, even though the spelling is close/the same. Even if the spelling you want would be allowed (i.e. restriction 1 is lifted), it would mean something different from the generic alternative func -<FS: FloatSequence>(left: FS, right: FS) -> CGFloat. The generic version says "there is a single type FS, which conforms to FloatSequence, and I get two arguments of the same type". The shorthand version that you want to write says "I receive two arguments, each having a protocol type (i.e. existential type) FloatSequence. The two arguments may or may not be related, I have no way to tell." These would not be the same function type; the latter is missing some important restrictions.

protocol P {}
struct S1 : P {}
struct S2 : P {}

func generic<T: P>(_: T, _: T) {}
func existential(_: P, _: P) {}

let s1 = S1()
let s2 = S2()
generic(s1, s1) // compiles
existential(s1, s2) // compiles
generic(s1, s2) // does not compile
existential(s1, s2) // compiles

[theblixguy]

I think it should be kept open until a decision is made on lifting the restriction (a couple of us are working on a proposal) or if this isn't a duplicate of an existing bug report. Please do update the bug report to only mention the 2nd problem, though.

[swift-ci]

Comment by Mitchell Robertson (JIRA)

Ok done @theblixguy

[AnthonyLatsis]

I'm raking this into a related family of bugs so that it doesn't get lost.

[slavapestov]

#42113