I’m surprised that Dir.readFile() and Dir.readFileAlloc() (or, rather, Dir.readFileAllocOptions()) seem more like distant cousins rather than siblings. I confess that I haven’t dug deeply to understand why allocRemainingAlignedSentinel() is the centerpiece, rather than what I might have expected, more of a gpa.alloc() using file.length(io) (which MIGHT have developed later, which might explain things), followed by a readSliceShort(), akin to that in Dir.readFile(), using the buffer allocated. I realize there’s some alignment treatment, there… but that surely isn’t the whole story, nor unique to the readFileAlloc() variant. Any insights would be appreciated. Also, none of these take OpenFileOptions like openFile() does, so a user can’t, e.g., set .mode to .read_only, for instance, which seems possibly so “natural” that I might even expect to find that set by default, within the implementation, but ….. tia.
Not all files have a length (even in Windows)! Think stdio, networking, etc.
allocRemaning* will do a single allocation if the length can be gotten (or limit if that is smaller) otherwise it follows the same growth pattern as an array list.
For more details: Loading a file to a string - #8 by vulpesx
it is .read_only by default per the default field value.
The other options are more niche than this API would typically be used as, so it is not unreasonable that it doesn’t take OpenFileOptions. But that doesn’t mean it shouldn’t either.
Ah, right, of course. Tunnel vision. And that’s the linchpin that makes everything else clear. Case closed, I think.