Tanner Gooding

https://github.com/dotnet/csharplang/discussions/686 should be closed once this is championed.

The proposal here has `regular` and `checked` operators because the default compilation settings result in a global `unchecked` context. However, the proposal as is also doesn't change the meaning of...

`unchecked operator +` and `operator +` need to be the same thing for back compat on existing types and code. So erroring would just force you to add an `unchecked`...

The main issue is trying to fit this onto 20 years of existing types. In the majority scenario, `unchecked` is the "default", because its the default setting for the compiler,...

There is nothing saying that `op_Addition` must overflow or not, just like there is nothing saying that `op_AdditionChecked` must overflow. If this was on a common interface (`IAddable`) then `BigInteger`...

> I was thinking that the expression a + b would bind to op_AdditionChecked, op_AdditionUnchecked or op_Addition based on: I think its worth expanding this table a bit more. Today...

> But this means depending on the compiler switch the checked operator and the regular could become the same but with different implementations. Which one is used then? Or do...

ECMA-335 itself doesn't define checked behavior for `shift` operators so it would make sense to allow user-defined variants. As for `Assignment` variants; that would be independent of the language and...

It is explicit that there is no "unchecked" variant. The design is such that if only `op_Subtraction` is defined, it is context oblivious. It has whatever behavior it has and...

> Is there concern around preserving the "intent" around why the second operand was restricted to int? The right hand side could be restricted to be some `INumber where TSelf...