If the proposal is accepted, I can happily do the legwork on implementation and testing. Or delegate it to the Go team, whichever is more efficient (the burden of reviewing untrusted code is often higher than the implementation, but I've contributed a couple fixes before, so I'm already familiar with the process).
My 2¢: We shouldn't promise that files from embed.FS implement ReaderAt - we should leave the door open for transparent compression of embedded files (for example) in future versions of Go and in alternative toolchains. But providing it as an optional interface upgrade, when available, seems reasonable to me.
embed.openFilecould trivially implement
Lines 348 to 381 in 15605ca
That's the entire proposal.
io.ReaderAtcan be emulated with
io.ReadSeeker, but this doesn't satisfy the goroutine safety of
io.ReaderAt: “Clients of ReadAt can execute parallel ReadAt calls on the same input source.”
This came up twice now on implementing
wazerosyscalls, that follow
preadsemantics: tetratelabs/wazero#967, and now tetratelabs/wazero#1037.
It got its own mention in that project's design rationale.
It is also of note that
io.ReaderAtis directly called out on the
fs.Filedocumentation: A file may implement io.ReaderAt or io.Seeker as optimizations.
The text was updated successfully, but these errors were encountered: