Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1. 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? SDH: negative shifts should be eliminated everywhere. There is (should be?) no such thing as overflow in bit ops, and there should be no promotion to BigInt.
  2. Changing bit ops Numbers methods to map directly to primitive ops means a breaking change with respect to negative bit-shift distances.  Is this intended/acceptable? SDH: No negative shifts. Patch that simply removes the negative shift stuff would be welcome.
  3. Assuming no overflow support, is there any reason bit ops should not all return long, as opposed to sometimes Object? SDH: Always long is good.
    1. If no, do we still need the BitOps interface? SDH: Good point, BitOps no longer needed.
    2. Can the bit ops fns be written using prim interfaces? SDH: Should be able to work with no interfaces, merely four overloads: long/long, long/Object, Object/long, and Object/Object.
  4. 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? SDH: Macro expansion is good, won't be unbounded unless your code is infinite. There is a patch that needs review/refreshing.

Related Tickets