Order of operation when creating constraint

[BrianSemiglia]

// Context
let view1 = UIView()
let view2 = UIView()
let window = UIWindow()
window.addSubview(view1)
window.addSubview(view2)
view1.widthAnchor == 50
view2.widthAnchor == (view1.widthAnchor + 150) / 2

// Expectation: (50 + 150) / 2
view2.frame.width == 100

// Actual: (50 / 2) + 150
// <NSLayoutConstraint: UIView.height == 0.5 * UIView.height + 150   (active)>
view2.frame.width == 175

[BrianSemiglia]

Pattern matching could be used to prevent orders that aren't supported or the math could be inversed within the Anchorage operator to achieve the desired effect using auto layout's native evaluation order.

[ZevEisenberg]

This stems from the fact that the operators are an interface into building a LayoutExpression, which contains a constant and a multiplier, and these are always assumed to be of the form:

y = multiplier * x + constant

In the sample that @BrianSemiglia posted, the original expression looked like this:

y = (x + constant) * multiplier

The user of this code would probably expect that the multiplier would distribute across the expression, resulting in this:

y = x * multiplier + constant * multiplier

However, order of operations is not honored. No matter the order, the constant and multiplier are both just set on the expression directly.

What should we do about it?

We could fix this by introducing more intermediate types to capture the order of operations, but that would be a breaking change: anyone who currently has some code that uses the current behavior is technically using it wrong, but if their code is working for them, correcting the multiplicative distribution would change their layout.

Instead, I think it might be a good idea to build those intermediate types to capture the order of operations, but then use availability/deprecation annotations to show the user a warning that they are using Anchorage incorrectly (i.e. "holding it wrong"). In my opinion, an Anchorage expression should look like the underlying expression it represents, which always takes the form y = mx + b.

[jvisenti]

I agree with @ZevEisenberg that the expression format should be enforced. I don't think there's a strong use case for the distributive property when building layout constraints, except in contrived examples.

Perhaps adding a deprecation/warning to the * and / overloads that take a LayoutExpression on the LHS could help? However, that would preclude valid expressions like

view2.widthAnchor == 50 + view1.widthAnchor / 2

[ZevEisenberg]

We could be strict about the ordering as well: anchor * multiplier + constant. Not sure if people are using other styles much. I'd be happy to run a patched branch against our internal projects and see if it turns up any issues.

Good call on the overrides. We may not need any new intermediate types; just stricter annotations on existing ones.

Edit: math is hard

[ZevEisenberg]

To clarify: I think it makes sense to accept any expressions that are unambiguously, algebraically equivalent to y = mx + b, and reject any that would be different if you apply distribution.