std.mmfile currently returns a class-type object which has no deterministic destruction guarantees, it seems much more appropriate for a resource to be reference counted.
AFAICT it's actually possible to "write" something to an mmfile then exit a program without anything being written due to it never being synced to disk because there's no guarantee that a destructor will run.
Comment #1 by issues.dlang — 2015-07-21T00:29:27Z
Last time I was looking at this, I came to the conclusion that if we wanted std.mmfile.MmFile to be @safe, what really needed to happen was that rather than returning an array from opSlice, it would need to return a reference-counted object that ensured that the memory wasn't unmapped until there were no more references to it floating around. And there's a decent chance that MmFile should have been a struct rather than a class (which seems to be what you're arguing for, but you talk about std.mmfile returning stuff, which doesn't make sense, since it's a module), but I'd have to look at it again to decide what my take on that would be at this point.
Regardless, std.mmfile could use some redesign. It's looks like it comes from D1 originally, so it predates ranges and @safe and all of that kind of fun stuff. So, while it's useful, it isn't really designed in the way that we'd design it now.
Comment #2 by robert.schadek — 2024-12-01T16:24:50Z