The Limits of Devirtualization

Would it be possible/helpful to break out the vtable into more granular, optional feature groups?

where ex: std.Io.VTable would have:

fs: ?std.Io.VTable.Filesystem;
async: ?std.Io.VTable.Async;
network: ?std.Io.VTable.Networking;
cryptography: ?std.Io.VTable.Cryptography;

etc.

If something requires ex: filesystem IO, but the VTable’s fs is null, then it would fall under a similar category of error to trying to pass a blocking IO implementation to something that explicitly requires concurrency.

This would make it easier to write custom IO implementations with incomplete feature sets. I don’t know if simply making feature groups optional would allow for better dropping of functions if they’re never used (I don’t think it does…), but I think it potentially could make it easier to think about optimizing stuff away if we explicitly allow it to be null.

9 Likes