Right now, details of the compilation target can be accessed through @import("builtin") in multiple ways:
builtin.target.cpu and builtin.cpu
builtin.target.os and builtin.os
builtin.target.abi and builtin.abi
builtin.target.ofmt and builtin.object_format
These are guaranteed to always be equivalent -- target is actually just defined like this:
pub const target: std.Target = .{
.cpu = cpu,
.os = os,
.abi = abi,
.ofmt = object_format,
.dynamic_linker = .init("/lib64/ld-linux-x86-64.so.2"), // this line varies per target
};
As such, having both around is entirely redundant, and has no benefit. This is a violation of "Only one obvious way to do things".
Since builtin.target bundles these values together in a logical way, it is the more useful declaration (it is easier and more concise to get a field from target than it is to reconstruct target from its fields). Therefore, this is a proposal to remove the following declarations from the generated builtin.zig source code:
These declarations should be marked as deprecated for one release cycle, and then entirely removed in a following one. I expect that the current definitions of cpu, os, abi, and object_format will just be inlined into the definition of target.
Right now, details of the compilation target can be accessed through
@import("builtin")in multiple ways:builtin.target.cpuandbuiltin.cpubuiltin.target.osandbuiltin.osbuiltin.target.abiandbuiltin.abibuiltin.target.ofmtandbuiltin.object_formatThese are guaranteed to always be equivalent --
targetis actually just defined like this:As such, having both around is entirely redundant, and has no benefit. This is a violation of "Only one obvious way to do things".
Since
builtin.targetbundles these values together in a logical way, it is the more useful declaration (it is easier and more concise to get a field fromtargetthan it is to reconstructtargetfrom its fields). Therefore, this is a proposal to remove the following declarations from the generatedbuiltin.zigsource code:cpuosabiobject_formatThese declarations should be marked as deprecated for one release cycle, and then entirely removed in a following one. I expect that the current definitions of
cpu,os,abi, andobject_formatwill just be inlined into the definition oftarget.