Comment by throwawaymaths

Comment by throwawaymaths a day ago

but that's not even the case, because it's certainly possible to write a function that receives an object that holds onto an io (and uses it in its vtable calls) that equally well receives an object that doesn't have anything to do with io [0]. The consumers of those objects don't have to care, so there's no coloring.

[0] and this isn't even really a theoretical matter, having colorblind object passing is extremely useful for say, mocking. Oh, I have a database lookup/remote API call, which obviously requires io, but i want fast tests and I can mock it with an object with preseeded values/expects -- hey, that doesn't require IO.

dminik 12 hours ago

I think in practice the caller still needs to know.

If I call `a.foo()` but `a` has and is using a stackless coroutine IO but the caller is being executed from a green thread IO then as was said before, I'm hitting UB.

But, I do like that you could skip/mock IO for instance. That's pretty neat.

Reply View 1 reply

throwawaymaths 7 hours ago

here is example code. you wont "use the wrong io".

    const VTable = struct {
      f: &fn (*VTable) void,
    };

    const A = struct {
      io: IO,
      v: VTable = .{ .f = &A.uses_io },
      fn uses_io(this: *VTable) void {
        const self: *A = @fieldParentPtr(.v, this);
        self.io.some_io_fn(...);
      }
    };

    const B = struct{v: VTable = .{.f = &void_fn}};
    fn void_fn(_: *VTable) void {}

    pub fn calls_vtable(v: VTable) {
      v.f()
    }

Reply View 0 replies