What's the deal with infix operator ~>

Development Standard Library
1

Some Swift libraries, such as ReactiveSwift and RxSugar, implement the <~ operator to model data binding. I've had internal discussions numerous times about the reversal operator ~> when data should flow to the right hand variable. Strangely, I discovered that we can't define this operator because it is already defined in the standard library.

I noticed that the infix operator ~> is defined in the standard library, but with a caveat:

// Workaround for <rdar://problem/14011860> SubTLF: Default
// implementations in protocols.  Library authors should ensure
// that this operator never needs to be seen by end-users.  See
// test/Prototypes/GenericDispatch.swift for a fully documented
// example of how this operator is used, and how its use can be hidden
// from users.
infix operator ~>

Not having access to rdar://problem/14011860, I'm not sure what the specifics are but the comment references the file GenericDispatch.swift. Looking at this file, it appears to be a sample swift source file that has little value. There's a comment at the top of the file that states "This file will ensure that the capability doesn't regress and give us a prototype to which we can refer when building the standard library.", but isn't this the intention of the swift-source-compat-suite?

Is there any hope for this operator to be removed in the stdlib so library authors can expose this in their API?

2

I think we removed all uses of it from the standard library now that we have protocol extensions, but we can't remove the operator declaration itself because other people are dependent on it being in the standard library.

3

That makes sense. Would there be any benefit of eventually deprecating and removing the operator from the next major Swift release? That would at least allow library authors to define their own precedence group, but I admit I can't think of a scenario where leaving it in poses any significant issues. It would simply be an odd, legacy artifact of the standard library.

1 Like
4

I'm not against it (and haven't thought heavily about it) but I don't see how you'd deprecate it, since you can't put in a replacement at the moment (the very redeclaration error you're seeing). We also just have general problems around operators and two libraries defining the same operator and all that, so while I don't want to take a small problem and tie it permanently to a big one, coming up with a better answer for how operators work in general might provide a way out for ~>.

1 Like