The function being called has to take into account thread safety anyway even if it doesn't do IO. This is an entirely orthogonal problem, so I can't really take

The function being called has to take into account thread safety anyway even if it doesn't do IO. This is an entirely orthogonal problem, so I can't really take it seriously as a criticism of Zig's approach. Libraries in general need to be designed to be thread-safe or document otherwise regardless of if the do IO, because a calling program could easily spin up a few threads and call it multiple times. > What if this function was designed with synchrony in mind, how do you prevent it taking a penalty guarding against a threaded version of IO? You document it and state that it will take a performance penalty in multithreaded mode? The same as any other library written before this point.