# The Limits of Devirtualization

**URL:** <https://ziggit.dev/t/the-limits-of-devirtualization/14015>\
**Category:** Brainstorming\
**Tags:** language, compiler, standard-library\
**Created:** [January 18, 2026, 10:48pm UTC](https://ziggit.dev/t/the-limits-of-devirtualization/14015 "2026-01-18T22:48:15Z")\
**Posts on this page:** 1\
**Showing post:** 78

<div class="post-metadata">

**Author:** ![Lowell](https://ziggit.dev/user_avatar/ziggit.dev/lowell/32/7145_2.png) [@Lowell](https://ziggit.dev/u/Lowell)\
**Post date:** [January 22, 2026, 7:57pm UTC](https://ziggit.dev/t/the-limits-of-devirtualization/14015/78 "2026-01-22T19:57:20Z")

</div>

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

where ex: std.Io.VTable would have:

```zig
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.

---

_[View the full topic](https://ziggit.dev/t/the-limits-of-devirtualization/14015)._