Proposal: IDisposable.Dispose() can reassign readonly fields

[RenderMichael]

Oftentimes I initialize otherwise readonly fields in a constructor and never intend to reassign them... except in setting them to null in Dispose().

The official guidance for implementing IDisposable involves setting large fields to null, but that cannot be done if they are readonly.

It's already taken for granted (even within the runtime) that using an disposed object yields undefined behavior dotnet/runtime#71548 (review), though double-disposing shouldn't throw and we try to throw an ObjectDisposedException.

I propose special-casing Dispose() to have the ability to modify readonly fields.

[iam3yal]

readonly is enforced by the runtime, the following readonly string s = ""; compiles into .field private initonly string s so there is a specific instruction that signals the runtime that it's a readonly field so they will have to make changes to the runtime first before they could relax the rules around it.

[RenderMichael]

Yeah this would require some runtime changes (hopefully not prohibitively expensive changes) for this language change.

[bernd5]

You can set readonly fields by using System.Runtime.CompilerServices.Unsafe.AsRef - it works because those objects / fields are allocated in regular heap memory.

[RenderMichael]

With this workaround, assigning to a readonly field may lower into code like this and runtime changes might not be necessary

[CyrusNajmabadi]

If you're going to mutate them, why not just make them mutable?

[RenderMichael]

Phrased differently, I want to the object's contract to guarantee the field be immutable, while continuing to follow IDisposable's official guidance around its disposal

[RenderMichael]

Dispose is special because it's invocation means the object's contract goes out the window, and continued use of the object leads to undefined behavior

[HaloFour]

Dispose isn't special as far as the language or runtime is concerned. I get the desire to want to have both readonly and the ability to reassign on dispose, but this doesn't seem to have posed a real practical concern in 20 years. Unless you plan on holding onto those "undefined" references for a while the GC is going to end up collecting both at the same time anyway.

[RenderMichael]

Can't argue with that last part 😁 and it's a perspective I understand. Thanks for the discourse

[CyrusNajmabadi]

means the object's contract goes out the window, and continued use of the object leads to undefined behavior

But that could be any interface. I'd say if you want this, make the fields mutable, but Mark them with an attribute. Then have analyzer restrict you from mutating the fields except in the allowed methods you care about.