Provide functions to replace == overloads (WIP)

[minimusic]

Resolving == types seems to really slow down build times on large projects. One idea is to provide an alternate set of anchorage functions that can replace ==, <=, >=, etc. So instead of viewA.topAnchor == viewB.topAnchor you would say viewA.topAnchor.pin(viewB.topAnchor) or something like that. I think there is still added value from Anchorage implementation, but maybe we should also consider a lighter-weight constraint helper to use with the newer/better Apple APIs (just adding edgeAnchors type conveniences, for example).

AnchorageFast.swift extends all the anchoragable classes. Not able to see a build time difference in the demo app, but it is a pretty small code base. Not sure about the match() naming. Also considered pin() or set() or some other variant of equals(). Would love to come up with an ideal set of names that are more clear in function, but relatively brief.

Still need to:

• Support other operators (~ or +, etc.)
• Replicate tests for new function
• Old functions should call new functions for single implementations
• Formally test build performance change
• Finalize function naming scheme

[chrisballinger]

Maybe matching AutoLayout naming conventions with equalTo, lessThanOrEqualTo and greaterThanOrEqualTo?

[minimusic]

matching AutoLayout function names could lead to confusion where you do/don't get the behavior you expect for an identical line of code (depending on which flavor you call)... but it is a direction to consider.

[minimusic]

.pin(), .pinUnder(), .pinOver()
.set(), .setMax(), setMin()

[ZevEisenberg]

Matching the name would provide limited utility over Apple's layout anchor API. Where we might be able to provide utility is to extend the existing layout anchor API with functions that look the same, but take parameters for multipliers and priority, plus non-operator versions of pinning centerAnchors, edgeAnchors, horizontalAnchors, and verticalAnchors.

Another angle: since we set translatesAutoresizingMaskIntoConstraints = false on the left-hand operand, we probably want to distance ourselves from the anchor API because our functions do magic that users of the anchors API are not expecting.

[jvisenti]

Changing how we write code based on compile times is unfortunate.

My 2cents is that Anchorage has always been about operator syntax for writing layout constraints, and if that changes then it's no longer Anchorage. The limited utility that Anchorage adds over the NSLayoutAnchor API aside from syntax (namely "composite anchors" like edgeAnchors and centerAnchors) could easily be ported to a separate, much smaller, library as @minimusic says. I also feel that AnchorageFast.swift is misleading because "fast" almost always implies faster runtimes, which I don't believe is the case here.

[chrisballinger]

We ended up taking an alternate route, there are now some less overloaded operators: #93