> There's an important behavioral difference between Scala 2 and 3: in 2, @inline was merely a suggestion to the compiler, whereas in 3, the compiler unconditionally applies the inline keyword. Consequently, directly replacing @inline with inline when migrating from 2 to 3 is a mistake.

This reminds me of a similar lesson C/C++ compilers had to learn with the "register" keyword. Early versions treated the keyword as a mandate. As compiler optimizers became more refined, "register" was first a recommendation and then ultimately ignored.

The C++ inline keyword is treated similarly as well, with different metrics used of course.

EDIT:

Corrected reference to early C/C++ keyword from "auto" to "register".

▲

TuxSH 2 days ago | parent | next [-]

> The C++ inline keyword is treated similarly as well, with different metrics used of course.

You are thinking of C's inline/static inline.

C++'s "inline" semantics (which are implied for constexpr functions, in-class-defined methods, and static constexpr class attributes) allow for multiple "weak" copies of a function or variable to exist with external linkage. Rather than just an optimization hint it's much more of a "I don't want to put this in any specific TU" these days.

▲

cpeterso 3 days ago | parent | prev | next [-]

Do you mean the ‘register’ keyword?

	▲	AdieuToLogic 3 days ago \| parent \| next [-]
		My root-cause analysis: I was visualizing Scala method definitions and associated the language's type inference with keyword use, thus bringing C++'s "auto" keyword to mind when the long-since deprecated "register" keyword was the correct subject. It would appear LLM's are not the only entities which can "hallucinate" a response. :-D
	▲	AdieuToLogic 3 days ago \| parent \| prev [-]
		> Do you mean the ‘register’ keyword? Yes I did, my bad.

▲

kokada 2 days ago | parent | prev [-]

And now we have things like `__attribute__((always_inline))` for GCC where you are completely, 100% sure that you want to inline :).