# Some cool language tricks

**URL:** <https://ziggit.dev/t/some-cool-language-tricks/18130>\
**Category:** Explain\
**Tags:** language\
**Created:** [October 28, 2026, 6:49pm UTC](https://ziggit.dev/t/some-cool-language-tricks/18130 "2026-10-28T18:49:41Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![InspectorBoat](https://ziggit.dev/user_avatar/ziggit.dev/inspectorboat/32/10410_2.png) [@InspectorBoat](https://ziggit.dev/u/InspectorBoat)\
**Post date:** [October 28, 2026, 6:49pm UTC](https://ziggit.dev/t/some-cool-language-tricks/18130/1 "2026-10-28T18:49:41Z")

</div>

#### 1. Figuring out if a value is comptime

```zig
pub inline fn comptimeKnown(val: anytype) bool {
    const Tuple = @TypeOf(.{val});
    return @typeInfo(Tuple).@"struct".field_attrs[0].@"comptime";
}

```

This one is pretty straightforward if you know how `comptime` fields work.

#### 2. Figuring out if a value is `comptime`, part 2

`comptime` fields are being debated for removal. This absolutely devious workaround was posted by `Fri3dNstuff`, at [https://codeberg.org/ziglang/zig/issues/32045#issuecomment-13664645](https://codeberg.org/ziglang/zig/issues/32045#issuecomment-13664645).

```zig
pub inline fn comptimeKnown(x: anytype) bool {
    const pair: struct { @TypeOf(x), usize } = .{ x, 0 };
    return @TypeOf(" "[0..pair[1]]) == *const [0]u8;
}

```

How it works:

1. A value must either be entirely `comptime`-known or entirely runtime-known. A value is `comptime`-known `iff` it depends solely on other `comptime` values. (Although note that `comptime`-ness gets lost at function call boundaries, which is why the one in the snippet is `inline`)
2. The literal 0 is always `comptime` known. This means that the variable `const pair = .{ x, 0 }` is `comptime`-known `iff` iff `x` is `comptime`-known.
3. When slicing arrays using `array[start...end]`, if the `start` and `end` are both `comptime` known, the type of the expression is a pointer to an array (`*const [end-start]T`). the type of the slicing expression is `[]const T`.
4. If `pair` is `comptime`-known (which, again, depends solely whether `x` is `comptime`-known), `pair[1]` is also `comptime`-known, so the slicing expression `" "[0..pair[1]]` has a pointer-to-array type.
5. Otherwise, `pair[1]` is only runtime known, so the slicing expression `" "[0..pair[1]]` has a slice type.

#### 3. Pseudo @ResultType

[Proposal: `@Result` to match cast builtins inference API · Issue #16313 · ziglang/zig · GitHub](https://github.com/ziglang/zig/issues/16313) may have been shot down, but you can still provide much of its proposed utility (in certain situations) via the magic of decl literals!

For example, in a `pub fn Vector3(T: type)` struct:

```zig
pub fn splat(n: T) @This() {
    return .{ .x = n, .y = n, .z = n };
}
pub fn mul(self: @This(), factor: @This()) @This() {
    return .{
        .x = self.x * factor.x,
        .y = self.y * factor.y,
        .z = self.z * factor.z,
    };
}
pub fn floatCast(vec: anytype) @This() {
    return .{
        .x = @floatCast(vec.x),
        .y = @floatCast(vec.y),
        .z = @floatCast(vec.z),
    };
}

const foo: Vector3(f64) = ...;
const bar: Vector3(f32) = .mul(.floatCast(foo), .splat(1));

```

This leads to a kind of pseudo-Łukasiewicz notation I quite like.

#### 4. `std.array_hash_map`

Not technically a language trick, but I wanted to include it anyways.  
Are you tired of writing iterators like this?

```zig
var entries = hash_map.iter();
while (entries.next()) |entry| {
    const key = entry.key_ptr;
    const val = entry.value_ptr;
}

```

`array_hash_map` to the rescue! Since values are stored densely packed in a regular MultiArrayList, iterating becomes a breeze:

```zig
for (hash_map.keys(), hash_map.values()) |key, value| {}

```

It’s so nice! As an extra bonus, `array_hash_map` variants are `Unmanaged` by default.