cancername
cancername
The clamping behavior the proposal suggests for these builtins is **non-obvious** and does not follow from the names at all. Having four different builtins for the exact same behavior on...
> a simple test shows that it still does the safety checks, runtime and/or comptime (comptime checks might be less of an issue in this respect I believe, but runtime...
> For integers one can bypass safety checks completely. Yes, that's because `@truncate` is a well-defined operation that is different from `@intCast`, unlike `@floatFromInt`. Consider MIPS, where `@intCast` can save...
`cvtss2si` might not return garbage, and even if it does because you masked the exception, that isn't portable. If you know that a value will be in range, `@floatFromInt`. If...
I believe it's the latter.
Seems like a bug then.
For purposes of consistency with C (compiler `__builtin_expect` vs the common `#define LIKELY(x) __builtin_expect(x, 1)`), it seems better to name it `likely`.
Since the user can implement a likely or unlikely pretty easily themselves when a second field is added: ``` inline fn likely(x: bool) bool { return @expect(x, true); } inline...
Should `likely` and `unlikely` functions be part of the standard library? On one hand, they're one-liners any user can easily write, on the other hand, everyone writing their `likely` and...
Will start working on this.