Bypassing specialization for proper RO and R/W support

[Oakchris1955]

On Jul 21, 2025, 11:17 AM GMT+0, @danielhenrymantilla wrote:

---

@Oakchris1955 I think there are other interesting ways to tackle this problem.

There are two approaches worth exploring here:

Option 1: downcast-to-dyn helper

/// Helper trait "alias" to bundle three traits under one `dyn`.
trait ReadSeekWrite : Read + Seek + Write {}
impl<T : ?Sized + Read + Seek + Write> ReadkSeekWrite for T {}

trait MaybeWrite {
    fn as_writeable(&mut self) -> Option<&mut dyn ReadSeekWrite> {
        None
    }
}

impl<T : Read + Seek + Write> MaybeWrite for T {
    fn as_writeable(&mut self) -> Option<&mut dyn ReadSeekWrite> {
        Some(self /* : &mut T as &mut dyn ReadSeekWrite */)
    }
}

• alongside a few impl MaybeWrite for MyNonWriteableType {} as-needed.

Then, on use site (S : Read + Seek + MaybeWrite):

if let Some(storage) = self.storage.as_writeable() {
    // Profit™: `dyn`-dispatch gets devirtualized thanks to compile-time knowledge of `S`, here
    storage.sync_sector_buffer(…)
}

Option 2: make FileSystem itself generic over its Write-ability

/// Type-level `enum`
mod Writability {
    #![allow(nonstandard_style)]
    pub enum ReadOnly {}
    pub enum ReadWrite {}
}

struct FileSystem<'lt, S, W> {
    …
    _writability: PhantomData<fn() -> W>,
}

impl<S : Read + Seek> Foo for FileSystem<'_, S, Writability::ReadOnly> {
    …
}

impl<S : Read + Write + Seek> Foo for FileSystem<'_, S, Writability::ReadWrite> {
    …
}

• and keep your two constructors, but producing types with either Writability;

• and have all usages of FileSystem<S> over a generic S: Read + Seek also be generic over <W>;

• except the concrete cases requiring Writability::ReadWrite knowledge, where you'd hard-code that param.

There is even a way to do a hybrid approach of these two (so you never need to "hard-code Writability::ReadWrite except at construction-site).

[Oakchris1955]

I should probably say here that my way of "bypassing" specialization isn't as concrete as I thought. If someone obtains a FileSystem using from_ro_storage and the storage isn't actually RO, ie. it implements Write, all write-related methods can be called, but since the sync_fn field is actually None, nothing works as intended.

[Oakchris1955]

In order to fix the above issue I thought of creating 2 separate FileSystem structs, one RO and the other R/W, where the RWFileSystem would be a thin wrapper around the RO one but with the Write-related methods. Unfortunately, I quickly run into issues with the File struct, since a RWFile would have to borrow both a RWFileSystem and a ROFile, which would also borrow a ROFileSystem, so we would need 2 mutable references to the same object, which in Rust is unsafe.

So, I came up with another approach (hopefully without any loopholes). We keep our approach of having a single FileSystem struct for both RO and R/W storage mediums, but now with only 1 constructor for both RO and R/W storage mediums. The FileSystem struct will keep both unmount_f and sync_f fields, both of which will be initialized to None. Then, whenever a Write operations occurs, it will call a function that will set those fields to the corresponding function pointers. The load_nth_sector checks if the sync_f field has Some value, which if true will call that function pointer as usually but right after that it will set it back to None so that the next load_nth_sector call doesn't perform an unnecessary write to the storage medium.

All that has now been implemented with 0828f0d. I will keep this discussion open for a week to see what you, @danielhenrymantilla, or other people think and I will then close it as resolved