US111 - Comments in example use the wording "constraints" as a subject - should this be "the constraints on "?

The comments use "constraint" with two different meanings:

• To refer to an atomic constraint expression in the associated constraints of a declaration:
  • // ambiguous, !sad<T> constraints are not formed from the same expression refers to the atomic constraint expressions !sad<T> in the associated constraints of both declarations of f1
  • // OK, !sad<T> constraints both come from not_sad refers to the atomic constraint expressions !sad<T> in the associated constraints of both declarations of f2
• To refer to the associated constraints of a declaration:
  • // error, constraint not satisfied due to substitution failure refers to the associated constraints of f3.

This overloaded meaning for "constraint" is fairly common usage when discussing code, it's annoying to always clearly specify "atomic constraint expression" or "associated constraints" when the context generally makes it clear. Given that the point of examples in the Standard is to explain things to folks who don't know that the context makes the meaning clear and why, we should avoid overloading meanings like this.

I suggest using "!sad<T> atomic constraint expressions" in the first two comments and "associated constraints not satisfied" in the third.

@CaseyCarter Thanks for your suggestions. So for US111, we now have this in [temp.constr.op] :

  int i1 = f1(42);      // ambiguous, !sad<T> atomic constraint expressions are not formed from the same expression
  ...
  int i2 = f2(42);      // OK, !sad<T> atomic constraint expressions both come from not_sad

Which still doesn't quite read right to me. What do you think?

Which still doesn't quite read right to me. What do you think?

\grammarterm{expression} in the first comment may help. A cross-reference to [temp.constr.atomic] may help more.