Prevent duplicate constraints.

[davidbjames]

Adding constraints should probably prevent duplicates.

From basic testing, duplicate constraints do not appear to cause technical problems. However, if those constraints are iterated/manipulated it could cause problems.

ConstraintBatch would need to perform a "union" instead of "append". (See here.) Unfortunately, even though NSLayoutConstraint is Hashable, apparently duplicate constraints still have unique hash values, so Set can't be used to remove duplicates. You would need to do an Equatable based "union" instead. I have some code for that here.

[ZevEisenberg]

It's typically the developer's responsibility to avoid creating duplicate constraints, but this could be an interesting way to help avoid developer error. Are you running into situations where you're creating duplicate constraints when you don't mean to? I'm wondering if there's anything we can do in terms of the API to make this less likely in the first place.

[davidbjames]

I'm building a library that supports declarative layouts. There is nothing preventing a developer from inadvertently adding duplicate constraints. This conflicts with another part of my API that supports changing constraints constants, which involves querying the UIView.constraints property. The problem, is if there are duplicate constraints, then it throws off querying the constraints.

[davidbjames]

Just realized ConstraintBatch.constraints is not per layout object, but per instance of itself, so "union'ing" there would be pointless.

In answer to your question about making it less likely to occur, I personally wouldn't pollute the API (it's already excellent). It's not that critical.

The only thing for it is to preemptively check for duplicates before each is added, but I'm beginning to wonder if Apple had a reason to allow duplicate constraints to be set in the first place.

[ZevEisenberg]

I can think of a pathological case where you'd want duplicate constraints: you add two identical pinned width constraints with a low priority, then later you change the .constant of one of them to a different value. That's a legitimate use case, and you wouldn't want to be warned about it.

[jvisenti]

Agree with @ZevEisenberg that's it's the developer's responsibility to decide what constraints to add, and to avoid duplicates. Closing for now.