> From: "Kevin Bourrillion" <[email protected]> > To: "Brian Goetz" <[email protected]> > Cc: "daniel smith" <[email protected]>, "valhalla-spec-experts" > <[email protected]> > Sent: Thursday, June 16, 2022 9:16:43 PM > Subject: Re: User model stacking: current status
Hi Kevin, >> And arrays are much worse. > Arrays in general, or just the one single construction path `new > TheType![size]` > (or `new TheType.val[size]`)? I would just say please give us new Arrays > methods or syntax that create and fill at once, and we'll get busy clamping > down on everything else. It does work even in simple cases, by example try to write ArrayList or ArrayDeque with that primitive (array + fill). Rémi >> On 6/15/2022 2:10 PM, Kevin Bourrillion wrote: >>> On Wed, Jun 15, 2022 at 10:51 AM Brian Goetz < [ >>> mailto:[email protected] | >>> [email protected] ] > wrote: >>>> - If we spelled .val as !, then switching from P[] to P![] not only >>>> prohibits >>>> null elements, but changes the layout and _introduces tearing_. Hiding >>>> tearability behind "non-null" is likely to be a lifetime subscription to >>>> Astonishment Digest, since 99.9999 out of 100 Java developers will not be >>>> able >>>> to say "non-null, oh, that also means I sacrifice atomicity." >>> Well, that's what you opted into when you... wait a minute... >>>> The link you probably want to attack is this last one, where you are >>>> likely to >>>> say "well, that's what you opted into when you said `non-atomic`; you just >>>> happen to get atomicity for free with references, but that's a bonus." >>> Your Kevin's Brain Emulator has gotten pretty decent over time... check >>> whether >>> the next things it said were these (probably so): >>> A good clean Basic Conceptual Model For Novices is allowed to have a bunch >>> of >>> asterisks, of the form "well, in $circumstance, this will be revealed to be >>> totally false", and that's not always a strike against the model. How do we >>> discern the difference between a good asterisk and a bad one? How common the >>> circumstance; how recognizable as being a special circumstance; how >>> disproportionate a truth discrepancy we're talking about; etc. >>> I know I've said this before. If I'm in a class being taught how this stuff >>> works, and the teacher says "Now unsafe concurrent code can break this in >>> horrible ways, and in $otherClass you will learn what's really going on in >>> the >>> presence of data races" ... I feel fully satisfied by that. I know I won't >>> get >>> away with playing fast and loose with The Concurrency Rules; I'm not >>> advanced >>> enough and might never be. (Many people aren't but don't know it, and >>> therein >>> lies the problem, but do we really have much power to protect such people >>> from >>> themselves?) >>> I could be wrong, but I suspect this kind of viewpoint might be more common >>> and >>> respected in the wider world than it is among the rarefied kind of >>> individuals >>> who join expert groups, no offense to anyone here meant. You're always >>> going to >>> see all the details, and you're always going to want to see all the details. >>> The general public just hopes the details stay out of their way. When they >>> don't, they have a bad day, but it doesn't mean they were better served by a >>> complex model that tried to account for everything. >>> -- >>> Kevin Bourrillion | Java Librarian | Google, Inc. | [ >>> mailto:[email protected] | >>> [email protected] ] > -- > Kevin Bourrillion | Java Librarian | Google, Inc. | [ > mailto:[email protected] | > [email protected] ]
