promote `std.mem.Alignment` to `std.builtin` and use it as the type of alignments instead of `usize`

[andrewrk]

The type currently lives here:

zig/lib/std/mem.zig

Lines 21 to 73 in 4e700fd

	/// Stored as a power-of-two.
	pub const Alignment = enum(math.Log2Int(usize)) {
	@"1" = 0,
	@"2" = 1,
	@"4" = 2,
	@"8" = 3,
	@"16" = 4,
	@"32" = 5,
	@"64" = 6,
	_,
	pub fn toByteUnits(a: Alignment) usize {
	return @as(usize, 1) << @intFromEnum(a);
	}
	pub fn fromByteUnits(n: usize) Alignment {
	assert(std.math.isPowerOfTwo(n));
	return @enumFromInt(@ctz(n));
	}
	pub fn order(lhs: Alignment, rhs: Alignment) std.math.Order {
	return std.math.order(@intFromEnum(lhs), @intFromEnum(rhs));
	}
	pub fn compare(lhs: Alignment, op: std.math.CompareOperator, rhs: Alignment) bool {
	return std.math.compare(@intFromEnum(lhs), op, @intFromEnum(rhs));
	}
	pub fn max(lhs: Alignment, rhs: Alignment) Alignment {
	return @enumFromInt(@max(@intFromEnum(lhs), @intFromEnum(rhs)));
	}
	pub fn min(lhs: Alignment, rhs: Alignment) Alignment {
	return @enumFromInt(@min(@intFromEnum(lhs), @intFromEnum(rhs)));
	}
	/// Return next address with this alignment.
	pub fn forward(a: Alignment, address: usize) usize {
	const x = (@as(usize, 1) << @intFromEnum(a)) - 1;
	return (address + x) & ~x;
	}
	/// Return previous address with this alignment.
	pub fn backward(a: Alignment, address: usize) usize {
	const x = (@as(usize, 1) << @intFromEnum(a)) - 1;
	return address & ~x;
	}
	/// Return whether address is aligned to this amount.
	pub fn check(a: Alignment, address: usize) bool {
	return @ctz(address) >= @intFromEnum(a);
	}
	};

It's quite a handy type and is used in for example Allocator now.

In a branch @jacobly0 added this method:

    pub inline fn of(comptime Type: type) Alignment {
        return comptime .fromByteUnits(@alignOf(Type));
    }

Which, incredibly, is more convenient syntactically to use than actual alignment syntax. So, why not embrace this type in the language?

test {
    var x: u32 align(@alignOf(u64)) = 1234;
}

Would continue to work, but also could be written:

test {
    var x: u32 align(.of(u64)) = 1234;
}

Pretty small change, would only affect align() syntax, @alignOf, and type info. Downside would be the language gains another dependency on std.builtin.

[InKryption]

This would also turn []align(std.heap.page_size_min) u8 into []align(.fromByteUnits(std.heap.page_size_min)) u8, which makes it kind of seem to just trade off the convenience of one case for another.

[alexrp]

This would also turn []align(std.mem.page_size_min) u8 into []align(.fromByteUnits(std.mem.page_size_min)) u8, which makes it kind of seem to just trade off the convenience of one case for another.

Seems reasonable to add a helper decl on Alignment for this common case, e.g. []align(.page_size_min) u8.

[alexrp]

I guess my only concern with this proposal is that align(.@"1") is fairly annoying to type compared to align(1). A quick grep of std shows that this is quite a bit more common than align(@alignOf(...)).

[NicoElbers]

It may be reasonable to change align(.@"1") to align(.none) if I'm understanding the status quo align(1) correctly

[alexrp]

To be clear, the 1 was just an arbitrary example; the same concern applies for any literal value.

[nektro]

align(1) would also be equivalent to align(.of(u8)) in this new scheme, right?