Proposal: Rename @trunc and @truncate

[Srekel]

There's both @trunc and @truncate. I think at least one of them should change name, but probably both?

Simplest solution:
@trunc -> @floatTruncate
@truncate -> @intTruncate

Alternatively (as suggested by @daurnimator):
Replace @trunc/round/ceil/floor and provide a single builtin that takes an enum:
@round(comptime T, value: T, mode: enum {Floor, Ceil, TowardsZero, AwayFromZero})

I think I prefer that solution for @trunc, but I feel like @intTruncate might be good anyway, to make it clearer.

[andrewrk]

Good catch, I hadn't noticed we had such similar names.

One thing to consider, although it doesn't necessarily mean not to do this, is that trunc matches the libc math function.

It's no coincidence - Zig semantics allows the compiler to replace calls to this builtin with calls to libc (when libc is being linked), as well as peephole optimizations that turn sections of code into calls to this builtin. When libc is not being linked Zig puts trunc & others in compiler-rt, so that they are still available.

I like the @round idea, but it does depart from the convention of using the math function names. That's OK though - let's not let C's old decisions hold us down.

For @intTruncate, I'm going to counter-propose @intTrunc. That builtin is one of the safe ones, so I'd like to avoid making the name more punishing to type.

[daurnimator]

I like the @round idea, but it does depart from the convention of using the math function names. That's OK though - let's not let C's old decisions hold us down.

One extra thing: if it's only going to be for floats, lets call it @floatRound?

Then we can "float round the ceiling" ;)

[ikskuh]

I like the idea of an explicit @round() with a mode as it reads more literal:
@round(f32, 1.5, .floor) ⇒ "Round 32-bit float 1.5 downwards"

[ghost]

I lean toward either obviously named functions

• @roundTowardNegative(v)
• @roundTowardPositive(v)
• @roundTowardZero(v)
• @roundTowardInfinity(v)

or obviously named enums

• @round(v, .TowardNegative)
• @round(v, .TowardPositive)
• @round(v, .TowardZero)
• @round(v, .TowardInfinity)

Both are very clear, thanks to keystrokes! Eliminates ambiguous @round() / .Round variants. These functions can also be implemented for fixedpoint numbers (toot).

As for @truncate(v), @truncateHigh(v) and @truncateLow(v) are more descriptive and handy, as we may want to truncate from different ends of the value! Communicate Intent Precisely!

[fengb]

I believe that @truncate should have "cast" in its name, e.g. @truncCast. This is currently the only type shifting builtin that does not (excluding @as). The casting behavior will be much less obvious once #5909 is implemented.

[daurnimator]

I believe that @truncate should have "cast" in its name, e.g. @truncCast. This is currently the only type shifting builtin that does not (excluding @as). The casting behavior will be much less obvious once #5909 is implemented.

A cast in zig is always a no-op in machine code, and is the programmer making as assertion to the type system about the values.

truncate is a bit-masking operation, not a cast.