Skip to content

CEP-0056: Bitwise and Shift Operators

Draft

Draft proposal for post-V1 bitwise and shift operators. V1 does not accept expression-level bitwise or shift operator spellings.

Summary

Catalyst should eventually decide whether to add expression-level bitwise and shift operators:

a & b
a | b
a ^ b
~a
a << b
a >> b

V1 keeps these spellings out of the expression operator surface. Boolean operations use and, or, and not, while & and | already have type-expression meanings for intersections and unions.

Motivation

Systems code often needs bit masks, flag sets, packed fields, low-level integer operations, and shift-based algorithms. Named functions can express these operations, but operator spelling is familiar and compact for integer-heavy code.

Proposed Direction

If accepted, bitwise and shift operators should use the same closed contract-backed operator model as equality, ordering, indexing, and arithmetic operators. Catalyst should not introduce arbitrary symbolic operator overloading just to support bit operations.

Possible contract families:

fn BitAnd(comptime Rhs: Type, comptime Out: Type) Type
fn BitOr(comptime Rhs: Type, comptime Out: Type) Type
fn BitXor(comptime Rhs: Type, comptime Out: Type) Type
fn BitNot(comptime Out: Type) Type
fn Shl(comptime Rhs: Type, comptime Out: Type) Type
fn Shr(comptime Rhs: Type, comptime Out: Type) Type

Operator lookup should follow the arithmetic operator model if that model is accepted: left-operand driven, no implicit operand conversions during lookup, and expected type may select the output type only when the enclosing context already provides a concrete expected type and exactly one visible implementation matches.

Design Questions

  • whether expression-level & and | create too much visual overlap with type intersections and unions;
  • whether bitwise negation should use ~a, a word operator, or a named function;
  • which shift-count types are accepted for primitive integers;
  • whether signed right shift is arithmetic, logical, or split into separate APIs;
  • how checked safety modes handle out-of-range shift counts;
  • whether primitive bitwise conformances live in the prelude as generic impls over SignedInteger(bits) and UnsignedInteger(bits);
  • whether flag-set and enum-like types should participate through the same contracts or through named APIs;
  • whether compound bitwise assignment forms such as &=, |=, ^=, <<=, and >>= belong with this proposal or with compound assignment operators.

V1 Compatibility

V1 rejects expression-level bitwise and shift operator spellings. Code should use explicit named APIs for bit operations until this proposal is accepted.