- Sponsor
-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
allow configuration of error set tag type via a public const in the root source file #786
Comments
Further proposal:For performance reasons it would be nice if One way we could do this is by allowing the ErrorSet type to be declared via an enum in the root file (rather than the original proposal of an integer type). Lets make the restriction that it must be a non-exhaustive enum. A straightforward setup, just declaring the error set size: pub const ErrorSetType = enum(u8) { _ }; Mapping errno: pub const ErrorSetType = enum(u32) {
PermissionDenied = std.os.EPERM,
FileNotFound = std.os.ENOENT,
ProcessNotFound = std.os.ESRCH,
// etc.
_,
}; |
What should be the max size of an error specified by the user? as @MasterQ32 pointed out, even u32 requires a LOT (34 gb) of source code to use up fully. I think u32 is a good limit. https://freenode.irclog.whitequark.org/zig/2021-02-23#1614089709-1614090346; |
I don't know if the language can take advantage of this, but I think |
I think we kinda create a problem by allowing multiple errors with the same name. We could instead force user's to set the uint size of the error, and then let them handle the casting between different error types. It would be more verbose (also more C like), and I feel it would help reduce ambiguity. |
Since errors are just enums you could force users to do this const Values = error(u32) {
zero,
one,
two,
}; And if they don't it can default to Anyway, hope this small thinking of mine prevents zig from having those "special cases" that often trip programmers up |
How would this interact with the global error set? Afaict, that would require that the backing integer for errors would have to be the minimum integer type specified by any error set referenced/used in the program, which just sounds like something bad waiting to happen. A way to mitigate this would be to force the user to specify the maximum backing integer type for the error set, which brings us right back to this original proposal, making your suggestion somewhat superfluous. |
I never thought of it... but now you you point it out, we would be forced to work with the global error set to make sure each error is unambiguous since 2 separate error types could get the same number and would be considered equal even though they were declared as separate errors 😂 and that would be very confusing! Thank you for helping me see this 😂 @InKryption |
So does zig literally have to resolve all errors globally? I can think of no other way to do it that would make it possible to resolve the errors on a per package basis since they are all unsigned integers |
Random idea |
I'm just realizing that zig is going to have trouble with DLL's, and that could be a problem I am aware of Fast Binary Patching (which is totally epic), but I question it's viability in a browser environment. |
I see three options, all feel not so good to me, but just putting it out there for discussion.
|
Here's an idea that I feel is being overlooked:
Given that you have 65536 possibilities, this should be sufficient for any possible task, even having millions and millions of error sets. This seems like a sufficient method and gets rid of all the over-complexity that I've seen in this thread. |
This flag was added in ziglang#17532 to close ziglang#786, but the language reference was never updated to reflect the change.
This flag was added in ziglang#17532 to close ziglang#786, but the language reference was never updated to reflect the change.
Implementation reverted in 6dc45e7 |
Right now error sets are hardcoded to codegen to a
u16
.Ideally, zig would choose an appropriate sized integer based on the total number of error values in the compilation, but the user may do
@sizeOf(SomeStruct)
which has an error set type as a field before the entire compilation finishes analysis. This would create a circular dependency.One idea is to have the error set integer type have a default of
u32
, but in the same way that you can override the defaultpanic
handler in the root source file, you can override the error set integer type in the root source file by doing:Then you'd get a compile error if zig ran out of bits when choosing error values.
The text was updated successfully, but these errors were encountered: