On Mon, 26 Jan 2026 17:24:07 GMT, Maurizio Cimadamore <[email protected]> wrote:
>> Why `__witness`? Why can't it be an annotation like `@Witness` or even >> `@OperatorOverload`? Also, why an anonymous class??? > >> Why `__witness`? Why can't it be an annotation like `@Witness` or even >> `@OperatorOverload`? Also, why an anonymous class??? > > I will repeat the cautionary note stated in [this > comment](https://github.com/openjdk/valhalla/pull/1886#issue-3805376239): > >> Given the highly experimental nature of this work, nothing is settled in >> stone, and the comments below are mostly provided as a general guidance on >> how to use what's there. > > Commenting on superficial aspects such as the syntax we use to denote witness > is unlikely to be helpful at this stage of this project. > > @mcimadamore , what are the conditions to allow to a class to participate > > in having a witness, is being a value class sufficient? > > I was working on update Bfloat16 to have a witness for > > StandardFloatingPoint, but the client code wasn't recognizing the operators > > as valid for Bfloat16 arguments. Perhaps recognizing as allowing both > > Numerical and Orderable operators isn't work yet. > > After switching to a Numerical witness in a Bfloat16 value class, the code > > was accepted by the compiler, but ran into VerifyErrors at runtime. I'll > > send you more information off-list. Thanks. > > I've addressed the verifier issues here: > > https://git.openjdk.org/valhalla/pull/1968 > > As for the other issue you mentioned -- note that if you want to apply an > operation that belongs to the Numerical class, such as `+`, you need to have > a witness for Numerical. In other words, Bfloat16 needs to have witnesses for > both Numerical, StandardFloating point and Orderable. > > At the moment "type class extension" is a bit clunky, so the various > witnesses have to be provided and wired manually, as shown in this test: > > https://github.com/mcimadamore/valhalla/blob/2b56b03d734a2f82f9ef978d11811245ddc30a1d/test/langtools/tools/javac/typeClasses/TypeClassesOperatorResolutionTest.java#L34 Another note: in Haskell if you define an instance of a "sub" type class, it is mandatory that you have an instance of the "super" type class as well. That is, if you create an instance for Ord X, you need to also have an instance for Eq X handy. Such checks, if implemented in the current prototype would have least have avoided the "surprise" of `BFloat16` not working with respect to operators defined in `Numerical`. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1948#issuecomment-3800786647
