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

2022-05-26 Thread Kevin Bourrillion
On Thu, May 26, 2022 at 10:57 AM Dan Heidinga wrote: This will have high costs in the regular performance model as it will > Sorry, I should have mentioned up front that we'd have to be content with only the warnings we can spot at compile-time. I also should have been clear that none of this i

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

2022-05-26 Thread Dan Heidinga
On Thu, May 26, 2022 at 1:34 PM Kevin Bourrillion wrote: > > I'd like to bump this thread, as it seems to me to be the biggest obstacle to > bucket 2 being able to deliver value. > > * A warning not just on synchronization, but on *any* identity-dependence. This will have high costs in the regul

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

2022-05-26 Thread Kevin Bourrillion
I'd like to bump this thread, as it seems to me to be the biggest obstacle to bucket 2 being able to deliver value. * A warning not just on synchronization, but on *any* identity-dependence. * Not special for Integer etc.; it all needs to work through a general facility that anyone can use. *

Re: Nullity (was: User model stacking: current status)

2022-05-26 Thread Brian Goetz
I agree that Bucket 2 is largely uncontroversial (and largely implemented) and makes a sensible unit of delivery -- with the proviso that we need to properly message that it will not yet deliver the performance improvements that most users are hoping to get out of Valhalla. There'll be no heap

Re: Nullity (was: User model stacking: current status)

2022-05-26 Thread Kevin Bourrillion
Returning to this thread and going up a level or two: The real impact of this discussion, imho, should not be "now let's rush a declarative nullness feature out asap", or even "let's solve bucket 3 now in a way nullness will have to be harmonious with later". What I humbly suggest it points to is,