- Bit ops have primitive semantics by default (CLJ-772 bit ops to have primitive semantics by default, no conditionals, direct mapping to JVM primitive ops)
- No conditionals in default ops, like in Numbers.java
- Bit ops with boxed semantics are in another ns (CLJ-767 Remove support for non-primitive bit-shift operations)
- n-ary bit ops are inlined (CLJ-184 n-ary bit functions, also inlining of n-ary bit and math operations)
- Does "boxed semantics" mean negative shift distance flips the direction? Does it mean anything else, e.g., returning BigInt on overflow? Can this just be left to the API on BigInteger?
- Changing bit ops
Numbersmethods to map directly to primitive ops means a breaking change with respect to negative bit-shift distances. Is this intended/acceptable?
- Assuming no overflow support, is there any reason bit ops should not all return long, as opposed to sometimes Object?
- If no, do we still need the BitOps interface?
- Can the bit ops fns be written using prim interfaces?
- Support of n-ary ops via reduce causes a multiple orders of magnitude performance hit. Is unbounded expansion an acceptable solution for inline n-ary support? Is there work underway for better support for reduce when working with primitive-taking/returning fns?
- CLJ-767 Remove support for non-primitive bit-shift operations
- CLJ-441 Add unchecked coercions
- CLJ-772 bit ops to have primitive semantics by default, no conditionals, direct mapping to JVM primitive ops
- CLJ-184 n-ary bit functions, also inlining of n-ary bit and math operations
- CLJ-666 Add support for Big* numeric types to Reflector