My understanding of this problem is this: some of the internal implementations of std.meta are heavy, and providing them is often easy for people to abuse to make an implementation that looks more “clean” rather than an implementation that actually compiles with higher performance.
An example is this one which checks if an error is in a specific set of errors.
In this thread, the OP believes that the following solution is “verbose”.
pub fn inErrorSet(comptime err: anyerror, comptime Err: type) bool {
if (@typeInfo(Err).error_set) |error_set| inline for (error_set) |err_info| {
if (std.mem.eql(u8, @errorName(err), err_info.name)) {
return true;
}
};
return false;
}
Meanwhile, the solution with std.meta.FieldEnum seems much easier.
pub fn inErrorSet(comptime err: anyerror, comptime Err: type) bool {
return @hasField(std.meta.FieldEnum(Err), @errorName(err));
However, in fact, the previous solution get better perfmance. The latter solution copies all error names in the error set to generate its Enum type at compile time, and calls std.math.IntFittingRange internally just to check the maximum Tag size. These behaviors are actually not helpful for our needs and will harm compile-time performance.
The standard library status and ease of use of std.meta make it easier for users to write “simple” code that affects compilation performance.