Improve compile-time constants

[flofriday]

This is the discussion for the Improve compile-time constants proposal. A full text can be found here.

This proposal describes the current state of Kotlin's compile-time constants, outlines some inconsistencies within the feature and proposes changes to fix them.

[hfhbd]

Not part of this nice proposal, but reusing the annotation in FIR and Ir should also allow to mark const function in dokka (only stdlib due to internal visibility) and IntelliJ, shouldn't it?

Documentation is the biggest pain point of const values, why can I use 1.toByte() but not 1.ToUByte()?

[flofriday]

I tried to express that (for Dokka) with the following sentence, maybe it needs some rewording:

Additionally we will add special handling in Dokka to produce a note on those functions that they can be used inside a constant context.

In IntelliJ you already do see the annotation to let you know which functions can be evaluated, but adding a special rendering to it does sound like a good idea.

And lastly this proposal does aim to make it easier to make educated guesses and therefore proposes to include 1.toUByte() in the pool of evaluateable functions.

[PinkieSwirl]

This seems to be quite important for me, thanks for the proposal.

An example which I frequently come across is the usage of "text blocks" for annotation parameters. In java one can properly intend those, in kotlin only if empty space is ignored by the lib that provides them.