The point of LoadOpDontCare is that you can't obtain an instance of this value without invoking the unsafe function LoadOpDontCare::enable, so that you cannot use LoadOp::DontCare without using an unsafe block, to acknowledge the additional obligations you accept by using this feature.

But if LoadOpDontCare implements Default, then you can just call LoadOpDontCare::default and go on your merry way, no unsafe block required. For example, this test still compiles fine changed like so:

modified   tests/tests/wgpu-gpu/pass_ops/mod.rs
@@ -89,7 +89,7 @@ async fn run_test(ctx: TestingContext) {
             depth_slice: None,
             resolve_target: None,
             ops: wgpu::Operations {
-                load: wgpu::LoadOp::DontCare(unsafe { wgpu::LoadOpDontCare::enabled() }),
+                load: wgpu::LoadOp::DontCare(wgpu::LoadOpDontCare::default()),
                 store: wgpu::StoreOp::Store,
             },
         })],

There's probably some detail I'm missing, but I suspect that someone slapped Default in there because otherwise serde was unhappy trying to derive deserialization for LoadOp: the DontCare variant is defined like this:

    DontCare(#[cfg_attr(feature = "serde", serde(skip))] LoadOpDontCare) = 2,

and the serde(skip) attribute requires that the field's type derive Default.

For Firefox's sake, since LoadOp::DontCare is not part of WebGPU and is unlikely to become so, it would be better to simply not allow deserialization of DontCare at all.

For record and replay, I don't know what to do about this. As long as there is any way to deserialize this, then one can produce LoadOpDontCare tokens in safe code just by deserializing some JSON. I don't care about this if someone just does it deliberately because they hate unsafe blocks. But it does trouble me that permitting deserialization means that anything that consumes serialized wgpu stuff needs to be prepared for undefined behavior.

cc @cwfitzgerald