A modern programming language that makes developers happier.

kotlinlang

Hey, what do you think about adding some kind of  `Int/Double/String/LiteralExpression` feature to Kotlin? Ideally, this would be an interface, maybe even restricted to the compiler only. This would allow you to limit some helper functions to literals only, and don't pollute the namespace with helper methods.
Sample
```val IntLiteral.seconds: Duration get() = ...

fun getX() = 42
val secs = 2.seconds // valid, as 2 is a constant literal
val secs2 = getX().seconds //invalid, seconds can only be called from a IntLiteral```
Swifts similar implementation: <https://developer.apple.com/documentation/swift/swift_standard_library/initialization_with_literals>

What is usecase for this feature? Why do you want prohibit call some function on non-literal int?

<https://github.com/Kotlin/KEEP/issues/190#issuecomment-778821179>

Similar "problem" occurs proving a nice DSL for typed units, like `CSS`:
```val Int.px: CSSLenght get() = ...
val height = 10.px```

Your proposal will break one important usecase: extract to constant refactoring
Imagine that you have a lot of `10.px` calls which are semantically same and you want to turn them all to smth like this:
```const val DEFAULT_HEIGHT = 10
...
val heght = DEFAULT_HEIGHT.px```
So, with your proposal this won't compile

<@UKPEELJCW> I know :smile: Maybe the compiler could infer this case too by checking `const`, which is at compile time a literal (also used by optimization)

In such case rules for this `IntLiteral` fake type will be very tricky. What about such cases?
```const val IMPLICIT_CONST = 10
const val EXPLICIT_CONST: Int = 10

const val COMPILE_TIME_OPERATOR = 5 + 5

const val X = 5
const val Y: Int = 5
const val CONST_SUM = X + Y

// const funs are not part of language yet, but we are considering adding them
const fun computeHeight(): Int = ...

const val CONST_FROM_FUN = computeHeight()```
In which cases `SOME_CONST.px` will work and in which won't?

Good question... At first look, the `.px` call should work for all `const val` as well as `const fun`, but this will results in no advantage of the limitation...

Alternative would be disallowing using `const` with this feature

&gt; DEFAULT_HEIGHT.px
&gt; So, with your proposal this won't compile
<@UKPEELJCW> as I understand the idea of this proposal, this shouldn't compile because there should be no such thing as `.px` property of `DEFAULT_HEIGHT`

Yep. Extracting constants to `const val` is common usecase, and this proposal will breaks it

IMO providing helper functions/properties for literals only is intended to make these literals "typed", rather than just some numbers. So if one wants to extract a literal value to a constant, they should extract it in that "typed" form, e.g.
`const val DEFAULT_HEIGHT = 10.px`

That would require the typing function to be a constexpr (once/if that's a thing), wouldn't it?  Not sure if that will be possible for non-const classes.  I was toying with ideas for something similar, and wanted an annotation that would add a synthetic `.px` property for a `.toPx()` function, since imo `x.px` should be `x.toPx()` on non-constant values anyways (for readability, mostly).  Then any refactorings can just update to the non-literal version.

This will be possible and quite logical when we have const classes. 