Re: [External] Foo / Foo.ref is a backward default; should be Foo.val / Foo

On Mon, Apr 25, 2022 at 10:05 AM Brian Goetz wrote: > > 1. The option with fewer hazards should usually be the default. Users > won't opt themselves into extra safety, but they will sometimes opt out of > it. Here, the value type is the one that has attendant risks -- risk of a > bad default val

Re: We need help to migrate from bucket 1 to 2; and, the == problem

Above, when I said the proposed `==` behavior is "not a behavior that anyone ever *actually wants* -- unless they just happen to have no fields of reference types at all", I did leave out some other cases. Like when your only field types (recursing down fields of value types) that are reference typ

Re: Foo / Foo.ref is a backward default; should be Foo.val / Foo

On Tue, Apr 26, 2022 at 5:11 PM Kevin Bourrillion wrote: Nice question! I thought about it a little bit and this is my own first > take. I think *most* of the advice would be cross-cutting across param > types, return types, field types, etc.: > > If > 1. I don't want null to be included as a val

Re: Foo / Foo.ref is a backward default; should be Foo.val / Foo

On Tue, Apr 26, 2022 at 2:37 PM Dan Heidinga wrote: The question again is what's the primary reason(s) for exposing a B3 > (.val) vs B2 instance in APIs? What guidance would we give API > designers around the use of B3 .val instances? > Nice question! I thought about it a little bit and this is

Re: [External] : Re: Foo / Foo.ref is a backward default; should be Foo.val / Foo

I think this analysis is largely right. On the stack (parameters, returns, locals), the difference between B2/B3.ref and B3.val will be minimal; some extra register allocation pressure for the null channel, and that’s it. So I think its reasonable to say “doesn’t matter” for these. Where B3

Re: Foo / Foo.ref is a backward default; should be Foo.val / Foo

On Apr 26, 2022, at 12:37 PM, Dan Heidinga mailto:heidi...@redhat.com>> wrote: The question again is what's the primary reason(s) for exposing a B3 (.val) vs B2 instance in APIs? What guidance would we give API designers around the use of B3 .val instances? So one piece of guidance we could giv

Re: We need help to migrate from bucket 1 to 2; and, the == problem

On Apr 26, 2022, at 8:22 AM, Kevin Bourrillion mailto:kev...@google.com>> wrote: It's a great start, but the key difference is that we need to be able to apply this process to *our own* types, not just the JDK types. Really, we should see whatever we need to do for JDK types as a clue to what o

Re: Foo / Foo.ref is a backward default; should be Foo.val / Foo

Where is a B3 (.val) instance preferable to a B2 (B3 .ref) instance? What are the criteria that would make an API designer expose a B3 (.val) instance in their method descriptors? The primary benefit of a B3 (.val) instance over a B2 instance is memory density. This relates to the containers hold

Re: B3 ref model

On Apr 26, 2022, at 9:19 AM, fo...@univ-mlv.fr wrote: For me, L-type means: if you do not already know, you will discover later if it's a B1/B2/B3 when the class will be loaded. The preload attribute means: if you do not already know, you should load the class now (at l

Re: Foo / Foo.ref is a backward default; should be Foo.val / Foo

On Apr 26, 2022, at 8:45 AM, Kevin Bourrillion mailto:kev...@google.com>> wrote: I think I would insist that `.val` be spelled with only one additional character... or even that the value type be generated as the snake_case form of the name! Okay, this is a meaningful refinement that I find le

Re: We need help to migrate from bucket 1 to 2; and, the == problem

> From: "Kevin Bourrillion" > To: "valhalla-spec-experts" > Sent: Tuesday, April 26, 2022 5:12:54 AM > Subject: We need help to migrate from bucket 1 to 2; and, the == problem > So I want to make my class identityless. But -- whoops! -- I released it years > ago and it has lots of usages. And th

Re: B3 ref model

- Original Message - > From: "Brian Goetz" > To: "Remi Forax" > Cc: "daniel smith" , "valhalla-spec-experts" > > Sent: Tuesday, April 26, 2022 4:12:43 PM > Subject: Re: B3 ref model >> so if we have >> >> primitive class Prim { >> long value; >> } >> >> class Container { >> LPrim;

Re: Foo / Foo.ref is a backward default; should be Foo.val / Foo

On Tue, Apr 26, 2022 at 10:31 AM Dan Smith wrote: If the expectation is that a typical programmer is going to look over their > menu of types and choose between 'int', 'long', or 'Integer128.val', I > think we've heavily biased them against the third one. The syntactic > overhead is just too much

Re: Foo / Foo.ref is a backward default; should be Foo.val / Foo

> It's how I interpret our requirements, I guess? > > The vision of B3 is "user-defined primitives": that someone can define in a > library a type that can be used interchangeably with the existing built-in > primitive types. (We can debate whether "primitive" is the right word here, > but the

Re: Foo / Foo.ref is a backward default; should be Foo.val / Foo

On Apr 25, 2022, at 8:20 PM, Kevin Bourrillion mailto:kev...@google.com>> wrote: On Mon, Apr 25, 2022 at 7:52 PM Dan Smith mailto:daniel.sm...@oracle.com>> wrote: Yeah, I think this has to be the starting place, before we get into whatever other model simplifications, compatible migrations, et

Re: We need help to migrate from bucket 1 to 2; and, the == problem

It's a great start, but the key difference is that we need to be able to apply this process to *our own* types, not just the JDK types. Really, we should see whatever we need to do for JDK types as a clue to what other library owners will need as well. Understanding this now, I hope you'll reread

Re: B3 ref model

> so if we have > > primitive class Prim { > long value; > } > > class Container { > LPrim; prim; > } > > and Prim has been loaded before Container is seen by the VM, the VM can not > decide to flatten LPrim; to a long + a bit for nullability because the VM has > to ensure atomicity even if

Re: We need help to migrate from bucket 1 to 2; and, the == problem

How much of this is already covered by https://openjdk.java.net/jeps/390 ? On Apr 25, 2022, at 11:12 PM, Kevin Bourrillion mailto:kev...@google.com>> wrote: So I want to make my class identityless. But -- whoops! -- I released it years ago and it has lots of usages. And though I've labeled it a

Re: B3 ref model

- Original Message - > From: "daniel smith" > To: "Remi Forax" > Cc: "valhalla-spec-experts" > Sent: Tuesday, April 26, 2022 2:15:17 AM > Subject: Re: B3 ref model >> On Apr 25, 2022, at 3:08 PM, Remi Forax wrote: >> >> Ok, maybe i've not understood correctly how B3 model works, >> fo