New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
remove the "scope" parameter from std.log functions; introduce "std.log.scoped" functions #5943
Comments
I think that in its current state this proposal makes the API more ergonomic for trivial use-cases like hello world but less ergonomic for larger codebases and all libraries (which should always use a custom scope to allow for filtering). Having some kind of package-local configuration would make this a win for libraries however, and being able to override the config of imported packages would put the power in the hands of the library user as well as solving the issue of potential scope conflicts. I'd actually argue that hello world should just use |
I agree with @ifreund on the scope (heh) of |
I think the case where someone's going to want to call log functions with different scopes in the same file will be pretty unusual. As such, maybe the right thing to do is to provide the default scope on the As for init-exe, this isn't a library so it makes sense to pick a reasonable default scope like ".root" or ".app". |
how about a |
I don't think const log = std.log;
log.err("oops", .{}); // Uses the default_scope const log = std.log.scoped;
log.err(.main, "oops", .{}); |
Ooh, I like that scoped namespace idea. Brilliant. |
I would prefer a function in std.log that closes over the scope: pub fn scope(comptime s: any) type {
return struct {
pub fn err(comptime fmt: []const u8, args: any) void {
return log(.err, s, fmt, any);
}
// and other levels
};
}
pub const default = scope(.default); to be used as: const log = std.log.scope(.main);
log.err("oops", .{}); or otherwise: const log = std.log.default;
log.err("oops", .{}); |
I think I second this one.
…-- Email domain proudly hosted at https://migadu.com
|
I agree, @daurnimator's suggestion is better. Even if you want to mix scopes in the same file you can do something like const log = std.log;
log.scope(.main).err("oops", .{});
log.scope(.linker).crit("oof", .{}); |
* Add a std.log.scoped function that returns a scoped logging struct * Add a std.log.default struct that logs using the .default scope Implementation of daurnimator's proposal: ziglang#5943 (comment) Note that I named the function "scoped" instead of "scope" so as not to clash with the scope parameter that is used everywhere; this seemed a better solution to me than renaming the scope parameter to "s" or "log_scope" or the like.
Accepted Proposal
In effort to make logging more mainstream and ergonomic, this is a proposal to simplify the logging API, yet still provide the advanced functionality.
It's difficult to justify the "scope" parameter, for example, in Hello World. Here I propose to do this:
Hello World becomes:
A potential future improvement would be if we had package-local configurations and therefore could swap out the default log scope per-package. So packages that didn't need multiple scopes would be able to use the simpler log functions, and then get assigned an optional scope override by the application that used the package.
cc @ifreund
The text was updated successfully, but these errors were encountered: