I can buy that claim for the .NET CLR but I've never seen it nailed down properly the way Java did which gives me pause.

I worry about the Win95-era "Microsoft Pragmatism" at work and a concrete example which comes to mind is nullability. In the nice modern software I often work on I can say some function takes a string and in that program C# will tell me that's not allowed to be null, it has to be an actual string - a significant engineering benefit. But, the CLR does not enforce such rules, so that function may still receive a null instead e.g. if called by some ten year old VB.NET code which has no idea about "nullability" and so just fills out a null for that parameter anyway.

Of course the CLR memory model might really be set in stone and 100% proof against such problems, but I haven't seen anything to reassure me as I did for Java and I fear that if it were convenient for Windows to not quite do that work they would say eh, good enough.

▲

ameliaquining 5 days ago | parent [-]

There's a documented memory model (https://github.com/dotnet/runtime/blob/main/docs/design/spec...), does that not address this concern?

	▲	tialaramex 4 days ago \| parent \| next [-]
		So, the answer is that I've read that and I wasn't as reassured as I'd like. ECMA definitely isn't enough as it acknowledges. The platforms which exist today are fine. And future platforms? Well we're told it will be difficult to change these assumptions. Yeah, it would be difficult. For a comparison, the x86 has what that document calls TSO, a very strict "free" ordering (in fact you pay all the time, but, you can't opt out so in that sense it's free to get this ordering on Intel) so 1990s C++ written for Windows just assumes volatile means you get memory ordering -- even though that's not what that means. If you compile brand new code for x86 on Microsoft's compilers today you get the exact same promise, but if you target their ARM platforms you don't get that because it would be expensive so, too bad.
	▲	actionfromafar 5 days ago \| parent \| prev [-]
		It depends on what it says?