From e11cd2316bf752d42ab03807f40112e85cd46ab0 Mon Sep 17 00:00:00 2001 From: Andrew Kelley Date: Thu, 27 Aug 2026 13:41:18 -0700 Subject: [PATCH] langref: IINAH (Inline Is Not A Hint) maybe this meme will help spread the information better --- doc/langref.html.in | 26 ++++++++++++++++---------- 1 file changed, 16 insertions(+), 10 deletions(-) diff --git a/doc/langref.html.in b/doc/langref.html.in index a0ea833d85a0f16320c71a784a4fd35a8a855f1a..27e6e9723f001fcf7d8f879e3f144a1aeaa14347 100644 --- a/doc/langref.html.in +++ b/doc/langref.html.in @@ -2934,8 +2934,8 @@ or {#header_open|inline fn#}

Adding the {#syntax#}inline{#endsyntax#} keyword to a function definition makes that - function become semantically inlined at the callsite. This is - not a hint to be possibly observed by optimization passes, but has + function become semantically inlined at the callsite. {#link|Inline Is Not A Hint#} + to be possibly observed by optimization passes, but has implications on the types and values involved in the function call.

@@ -2947,16 +2947,22 @@ or

If {#syntax#}inline{#endsyntax#} is removed, the test fails with the compile error instead of passing.

-

It is generally better to let the compiler decide when to inline a - function, except for these scenarios:

+ + {#header_open|Inline Is Not A Hint#} +

Use of {#syntax#}inline{#endsyntax#} restricts what the + compiler is allowed to do. This can harm binary size, compilation speed, + and even runtime performance. In exchange, these use cases are addressed:

-

Note that {#syntax#}inline{#endsyntax#} actually restricts - what the compiler is allowed to do. This can harm binary size, - compilation speed, and even runtime performance.

+

For an alternative to {#syntax#}inline{#endsyntax#} that merely hints to the compiler + that inlining a function may be valuable, use {#link|@branchHint#}.

+ {#header_close#} {#header_close#} {#header_open|Function Reflection#} -- 2.54.0