Pending breakages: changes agreed or arguable that cannot ship before a major version

[Rafael-SOWNet]

"Maybe an issue on pending breakages would be appropriate. Remember to note to yourself to follow through on the next major version. Also, maybe noting down to promote experimentals and removing obsoletions would be appropriate."
— @Happypig375, #1009

This is that issue: the list of changes that are agreed or arguable but cannot ship in a minor, so that 3.0 has a docket rather than a memory. Nothing here is scheduled and nothing here is a defect report.

A change belongs on this list when it moves the value of existing user input, or removes a published member. A changed answer has gone in a minor here before, on the stated principle that correctness outranks compatibility — but every one of those was a wrong answer becoming right. Everything below is a deliberate convention change, which is a different thing and should not borrow that licence.

---

1. implies becomes right-associative

Raised on #1009. The grammar folds implies to the left; mathematics, Lean, Coq, Agda, Haskell and CSharpMath.Evaluation all read → to the right. Ours is the outlier, and CSharpMath reading it differently from us is a live inconsistency across a boundary we do not control.

It cannot go in a minor because it re-values existing text:

"false implies true implies false"     today  False        after  True

Nothing fails to compile; answers move silently. #1009 makes the printer state the grouping the grammar actually has, so the change is a one-line flip in ToString.Discrete.Classes.cs (from <=-on-the-right to <=-on-the-left) plus the grammar, and the round-trip tests written there keep it honest.

Also decide provided at the same time. It folds right today, which #1009 documents and tests. If implies moves to the right, the two agree and Syntax.md's rule becomes "^, implies and provided group to the right"; that is worth settling in one go rather than twice.

2. FreeVariables, VarsAndConsts, and a property that does not exist

Raised on #989.

"VarAndConsts is what it says: free variables and constants (pi and e). "Used variables" looks like another property." — @Happypig375

Measured on master at 6b93b401, against that definition. The documented example is Lambda(x, x * 2 + sin(y * pi)):

	today	by the definition above
Vars	x, y	—
VarsAndConsts	x, y, pi	y, pi — x is bound
FreeVariables	y	y

So VarsAndConsts returns bound names, and its XML example pins that. It is wrong for lambda, which is the one binder the library already honours elsewhere — and wrong for the other five (sum, product, integral, limit, derivative, set-builder) in the same way:

sum(k, k, 1, 3)      Vars = k    VarsAndConsts = k    FreeVariables = k

sum(k, k, 1, 3) is 6. Nothing about that value depends on k, and all three properties say it does.

The shape of the fix, which is three published properties moving at once:

• FreeVariables — extend "bound" from lambda to every binder. Its own doc comment currently defines bound as "a parameter of some outer lambda", which was accurate when written and is not now that CalculusOperator and ConditionalSet both declare a Var (Let a binder bind i, in every binder there is (#976) #986).
• VarsAndConsts — free variables and constants, per the definition above.
• A new property for "used variables" — every name that occurs, bound ones included. That is what Vars/VarsAndConsts do today, so the behaviour is not lost, it is renamed to something that describes it.

Part 1 of #989 — the %1 placeholder escaping — was a defect on any definition and is already fixed (#1000). This is part 2, which was always a design call.

3. Promote or retire the experimental features

MathS.ExperimentalFeatures (Sources/AngouriMath/Convenience/Experimental/) is 11 public members, documented as "features that might become stable in the future, but are not guaranteed to do anything useful or correctly at the current moment":

SolveDiophantineEquation · DecomposeRational ×2 · GetSineOfHalvedAngle · GetCosineOfHalvedAngle · ExpandSineArgumentMultiplied · ExpandCosineArgumentMultiplied · ExpandSineOfSum · ExpandCosineOfSum · SymbolicFormOfSine · SymbolicFormOfCosine

Each wants one of three verdicts, and the third is why this is on a breakage list:

• promote — move to the stable surface under its proper name, and commit to the answer;
• keep — it is still not guaranteed, and say what would settle it;
• remove — it has not earned a place, and deleting a published member is a major-version act.

Worth doing as one pass rather than one member at a time, because "experimental" is a promise about the whole namespace and it decays if it is never spent.

Note also that Experimental is a folder inside the kernel package, not a separate package as #746 describes it — see #1008.

4. Removing obsoletions — a standing practice, not a backlog

There are currently zero [Obsolete] members in the tree: 2.0.0 removed the lot. So there is nothing to schedule, and the note to keep is the rule:

Anything marked [Obsolete] during 2.x is removed at 3.0. An obsoletion that survives a major stops meaning anything, and 1.x accumulated a set precisely by never spending them.

5. Already-known decisions that belong on the same docket

AGENTS.md names three under "Decisions only a major version may take", all still open:

• Roots vs fractioned powers? #204 — roots versus fractional powers. SimplificationContract.md calls it "open and deliberately a major-version question".
• Syntax for Piecewise? #326 — the syntax for piecewise. Simplification pattern for Piecewise #327's simplification half shipped; the syntax was never touched and no design is recorded.
• Unify Codomain with a "provided ... in RR" condition #721 — unify Codomain with a provided … in RR condition. Named on Goal: Math OS — a ten-year vision for AngouriMath as an open mathematical reasoning platform #746 as a consumer of the retired expression-metadata item, and still open.

And one more that is breaking by construction:

• Complex Infinity #217 — complex infinity. It changes 1/0 from NaN, and every consumer branching on NaN is blast radius.

---

What this issue is for

To be read before the next major version is named, in the same way #746 is read before any version is named. It is not a plan and it does not commit anyone.

Anything added here should say what moves, what the old and new values are, and why a minor cannot carry it.

[Happypig375]

If VarsAndConsts better means used variables instead, change it to that definition too! Identify the correct design here.

[Rafael-SOWNet]

Measured on current master, and the answer is yes to your suggestion — with a correction to what I
wrote in item 2 above.

VarsAndConsts already means "used", and its own documentation says so

The XML example on all three properties uses lambda(x, x * 2 + sin(y * pi)) and lists:

Variables:              x, y
Variables and constants: x, y, pi
Only free variables:     y, pi

It lists x — the bound name — under variables and constants. So VarsAndConsts is documented
as every name occurring, and the implementation matches it exactly. My item 2 was wrong to call
that a defect, and wrong that it makes this a three-property breaking change. Nothing about
VarsAndConsts needs to move, and nothing about Vars, which is VarsAndConsts minus the constants.

What is owed there is wording, not behaviour: the summary says "set of unique variables", which does
not distinguish occurring from free. It should say occurring, and say that a bound name is
included on purpose, so that the next person does not read the lambda case as a bug the way I did.

The property that is actually wrong is FreeVariables, and only for the range binders

sum(k, k, 1, n)              free = { k, n }     wrong -- k is bound
product(k, k, 1, n)          free = { k, n }     wrong -- k is bound
integral(t * b, t, 0, 1)     free = { b, t }     wrong -- a definite integral binds t
integral(t * b, t)           free = { b, t }     right -- the indefinite integral is a function of t
derivative(t * b, t)         free = { b, t }     right -- d/dt denotes a function of t
lambda(x, x + y)             free = { y }        right
{ k : k > a }                free = { a }        right

It handles Lambda and ConditionalSet and nothing else. Σ and Π genuinely bind their index —
sum(k, k, 1, n) depends on n alone — and a definite integral genuinely binds its variable between
its limits.

The two that look like the same shape and are not: an indefinite integral and a derivative do not
bind. ∫ t·b dt is b·t²/2 + C, a function of t, and derivative(f(t), t) denotes a function of
t as well. Their current answers are right, and worth writing down precisely so that a later sweep
does not "fix" them into being wrong.

So the design, stated

property	means	status
VarsAndConsts	every variable or constant occurring, bound ones included	correct; document the word occurring
Vars	the same, minus constants	correct, derived
FreeVariables	not bound by an enclosing binder	incomplete: sum, product, and integral with limits

Is it still a pending breakage?

Narrower than item 2 claims, and I will correct that entry. VarsAndConsts and Vars do not
change at all. FreeVariables changes for three node shapes — anyone relying on a Σ index appearing
free gets a different answer, so it owes a BREAKING-CHANGES.md entry, but it is a wrong answer
becoming right rather than a convention being chosen, which by this issue's own criterion at the top
means it does not have to wait for a major version.

I would rather fix FreeVariables now, in its own PR with the three cases pinned, and leave this
issue for the changes that genuinely cannot ship before 3.0.

[Rafael-SOWNet]

Section 2's FreeVariables defect is fixed, and the two cases the section is careful to mark
as right have stayed right — which is the half worth checking, since the fix is the kind that
over-corrects.

Measured at c639d489 — master 1f3b02ae plus the pull request in flight for #233, which
touches only the integrator and cannot reach any of this.

The four that were wrong

                              filed here          now
sum(k, k, 1, n)               free = { k, n }     free = { n }
product(k, k, 1, n)           free = { k, n }     free = { n }
integral(t * b, t, 0, 1)      free = { b, t }     free = { b }
limit(t * b, t, 0)            free = { b, t }     free = { b }

limit is the one this section does not list; it is recorded in BREAKING-CHANGES.md under
"every limit", and it moved with the others.

The two that were right, and still are

integral(t * b, t)            free = { t, b }     unchanged -- the indefinite integral is a function of t
derivative(t * b, t)          free = { t, b }     unchanged -- d/dt denotes a function of t

Worth stating explicitly because "extend bound from lambda to every binder" is exactly the
change that would have swept these up too, and the distinction the section draws — a definite
integral binds its variable, an indefinite one does not — is not one a mechanical fix would
make on its own.

sum(k, k, 1, 3)

                 filed here    now
Vars             k             k
VarsAndConsts    k             k
FreeVariables    k             {} (empty)

So of the three properties the section says all wrongly report k, only FreeVariables has
moved — which matches what the later comment in this thread concludes should happen:
Vars and VarsAndConsts report what occurs, bound names included, and that is the
documented meaning rather than a defect.

One discrepancy in the record itself

The table in section 2 gives, for lambda(x, x * 2 + sin(y * pi)):

	today	by the definition above
FreeVariables	y	y

Measured now it is y, pi — and that is what FreeVariables's own XML example has always
printed (Only free variables: y, pi). So this is not a change and not a regression; the row
here reads y where the documented example reads y, pi. Flagging it only so that nobody
later reads the difference as the fix having leaked.

What this leaves

Sections 1 and 3 are untouched by any of the above, and section 2's remaining items are the
two that were always design calls rather than defects:

• VarsAndConsts returning bound names — which the thread has since argued is correct, since
  it reports occurrence.
• A new property for "used variables" — still not added.

So the defect in section 2 is closed; what is left of it is the naming question.

[Rafael-SOWNet]

Re-measured every item against the tree at 5d802bab rather than reading the docket back. Three of
the seven no longer hold.

item	now	verdict
1 implies right-assoc	Still true. AngouriMath.g:221-224 loops $value.Implies(...). false implies true implies false → False; false implies (true implies false) → True. LaTeX already folds right, and provided already groups right — so only implies moves.	Keep for the next major
2 FreeVariables / VarsAndConsts	No longer true. sum(k,k,1,n) → { n }, product → { n }, integral(t*b,t,0,1) → { b }, limit(t*b,t,0) → { b }. (The table in the body also says FreeVariables = y; it is and was pi, y.)	Drop. What is left is a word in a summary and an optional additive property — minor-version work
3 Experimental	Still true. Exactly 11 public static members, no kernel consumer, no verdicts	Re-scope, see below
4 Obsoletions	Still true. grep '\[Obsolete' over the kernel returns nothing, and reflection over the built assembly with DeclaredOnly agrees	Keep the rule
5 · #204	No longer true. sqrt(x) and x ^ (1/2) are the same entity — == is True, Complexity is 3 for both, 7 for both of sqrt(x) + sqrt(y). The gap came from 1/2 parsing as a Divf before 2.3.0. Only printing differs, and sqrt(x^2) is not collapsed	Re-scope. A print form does not move a value, so by this issue's own criterion it is a BREAKING-CHANGES.md entry, not a major
5 · #326	Still true, and piecewise(x provided x > 0, ...) round-trips. #813's near-miss now throws UnhandledParseException rather than an NRE	Re-scope. New syntax can be added in a minor while the incumbent keeps parsing; only removing the incumbent is a major act
5 · #721	No longer true as a breakage. #1090 merged: DomainConditionIn(Domain) is additive and Codomain is untouched. The issue's own last comment says "Done"	Drop
5 · #217	Still true. 1/0 → NaN, limit(1/x,x,0) → NaN, limit(1/x^2,x,0) → +oo	Keep, but it needs a design first

Two things this turns up that are not items

AGENTS.md is stale. Lines 597-598 list #204, #326 and #721 under "Decisions only a major version
may take". By the measurements above, #721 is done and #204 is not a value change — so two of its
three entries are wrong. That file is read as authoritative; I would correct it whatever is decided
here.

Item 3 does not have to wait for a major. Promoting an experimental member and keeping one are
both additive: a stable name plus an [Obsolete] forwarder on the experimental one can ship in a
minor. Only removal waits, and item 4's rule then governs it. So the eleven verdicts are worth
giving now rather than at the major — which also means item 3 stops blocking on the release.

Net

Of the seven, four survive as genuine breakages: implies associativity, removing whichever
experimental members are not promoted, removing the incumbent piecewise form if a new one is
adopted, and complex infinity.

Not re-measured

The [Obsolete] count on the F# and Interactive packages — I checked the kernel only — and whether
any external consumer switches exhaustively over node types.