Skip to content

Problematic default constraints -- restriction of syntax required

(by @yoav.hollander and @joel.greenyer)

Current status:

The current document says that default constraints can contain any expression, It further says:

  • Default constraints must be satisfied unless they are overridden. If this is not possible, an error must be raised.
  • A default constraint can only be overridden by another default or hard constraint which appears after it (in textual order).
  • The explicit way to override default constraints is with the remove default operator remove_default(). This operator has the effect of removing all prior default constraints on that parameter if any. After the use of this operator, new constraints on the parameter may be stated with new keep clauses.
  • A short-hand notation for implicitly overriding a default constraint can be used: A default constraint can be overridden directly with a keep clause, if the following two conditions are met:
    • The overriding keep clause is either an equality or a range constraint.
    • The overriding keep clause has the parameter as the only expression on the left side of the Boolean expression.

Problem:

Default constraints are about assigning a default value (or range) to a parameter: they are parameter-specific, indicating that it is this parameter for which there is a default constraint that can be overridden. Allowing arbitrary constraints as default constraints makes it unclear which parameters are constrained, and what are the implications of overriding -- it leads to very complex and non-intuitive cases that will confuse the users.

Example 1

Let's assume that there are the following default constraints:

keep(default x == 5)         # 1 
keep(default x > 5 or y < z) # 2 
keep(default r > j + foo(x)) # 3

What if we write then write:

keep(default x == 7)

Careful reading of the spec would tell you that all three lines above would be overridden at once. But this is not intuitive.

The default constraints in lines 2 and 3 should therefore not be allowed!

Example 2

Similarly, consider the two following cases:

# case1:
keep(default x < 5)
keep(default x == 10)

# case 2:
keep(default x == 10)
keep(default x < 5)

In case 1, overriding happens. In case 2, it does not happen, thus resulting in contradiction. This is really hard for users to see. It is easy to come up with more complex cases.

Proposal:

Default constraints should be syntactically limited to the shorthand notation for implicitly overriding, like

keep(default x == 5)