Add `intrinsics.likely` and `intrinsics.unlikely`

[Kelimion]

We have:

// Compiler Hints
expect     :: proc(val, expected_val: T) -> T ---

Please consider adding:

expect_not :: proc(val, expected_not_val: T) -> T ---
likely     :: proc(is_likely: bool) -> bool
unlikely   :: proc(is_unlikely: bool) -> bool

unlikely can be used in practice as likely(!test), but for code readability I'd suggest adding both.

Where likely and unlikely pass through the bool they're given, such that:

if foozle(1) && unlikely(barzle == baz) {

}

Is equivalent to the below, except for telling the compiler the branch is unlikely.

if foozle(1) && barzle == baz {

}

[krux02]

Not sure about the usefulness of expect_not as you can always write expect(<expr>, !value), can't you?

You get my full support for likely and unlikely.

[Kelimion]

Not sure about the usefulness of expect_not as you can always write expect(<expr>, !value), can't you?

You get my full support for likely and unlikely.

No, !value only works for booleans. You couldn't express expect_not(val, 42) like that, you'd have to write expect(val != 42, true) or expect(val == 42, false) but unlikely and expect_not are easier to search for if you want to find rare branches.

[Kelimion]

Maybe add likely and unlikely as builtins (so you don't have to import intrinsics) and add a deprecation tag to intrinsics.expect.

[github-actions[bot]]

Hello!

I am marking this issue as stale as it has not received any engagement from the community or maintainers 120 days. That does not imply that the issue has no merit! If you feel strongly about this issue

• open a PR referencing and resolving the issue;
• leave a comment on it and discuss ideas how you could contribute towards resolving it;
• leave a comment and describe in detail why this issue is critical for your use case;
• open a new issue with updated details and a plan on resolving the issue.

The motivation for this automation is to help prioritize issues in the backlog and not ignore, reject, or belittle anyone..