Sometimes it’s necessary to indicate that a function has received a request to do something but has not performed it yet. Semantically that’s different from void.
Could you use an enum of statuses? Like
const JobStatus = enum {
ready,
scheduled,
complete,
}
Or am I misunderstanding your ask completely?
From the request function, you can return a future value. In zig type system it can be a function that returns a type Future(Result)
with a single function pub fn value() Result
that blocks the thread until the value is resolved.
It happens often enough where you don’t need to know the eventual outcome. One thread is just announcing something has happened, with the expectation that that another thread would do something else in response but without a real need for anything to occur.
You can model this as an event callback struct
with a fire
function. You pass an instance of the callback struct when you create the request. The request calls fire
to announce that something happen.
You can have different implementations for the callback type where the fire
function can do nothing or can queue what happened.
A Future(void)
is also useful if you expect the event to fire once.
I think the ask is for a type which behaves like void
but conveys a semantic hint to someone reading the code?
Sounds like a job for a one-valued enum perhaps:
pub const NoWait = enum { nowait };
pub fn sendThreadMessage() NoWait {
// send a message to a thread
return .nowait;
}
test "One-valued enum" {
try std.testing.expectEqual(0, @sizeOf(NoWait));
_ = sendThreadMessage();
}
This should behave exactly like void
in codegen, since it has no size.
Exactly. An enum that I defined wouldn’t have universally agreed-upon meaning. Having a dedicated type would allow another programmer to understand the situation by looking at the code itself.
Maybe you could simply make a pr on github and add inside the Thread module something like this pub const nowait = {}
with a doc comment above to describe it and you would use it like so :
pub fn foo() Thread.nowait {
...
return Thread.nowait;
}
...
Ah, that actually makes sense, since the usage scenario always involves threads. So I’m thinking something like this:
const PerformanceReporter = *const fn (ops: usize) Thread.nowait(1, .overwrite);
Without me telling you I think you can guess want the arguments mean.
Yeah, I think it makes more sense, to put something inside the Thread namespace, instead of adding a new keyword that essentially aliases void