You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Inline vals aim to be a replacement of final vals with inferred literal types.
They inline by having a literal type as a return type.
In inline def terms, this is equivalent to transparent inline def returning the constant which is also stable.
```
inline val x = 3
transparent def y: Int = 3
```
Therefore, such a definition of an inline val is always a transparent inline.
```
/*transparent*/ inline val x = 3
```
If we define inline vals as always being transparent inline vals, then the constant type becomes an implementation detail rather than a restriction. This would imply that the following inline val are allowed.
```
inline val a: Byte = 1
inline val b: Short = 2
inline val c: Int = 3
```
Note that with literal types it is impossible to directly implement `a` and `b` as those need a type annotation to infer their type, but the type would be widened.
New `inline val` definition:
* An `inline val` is `transparent`
* An `inline val` is `final` or `abstract`
* The RHS of an `inline val` must be a pure constant value
Advantages
* Aligns better with inline defs
* Can define constant `Byte` and `Short`
The proposed implementation would just reuse the same literal constant mechanism but modify slightly type inference for inline vals. When we type an inline val we use the return type
to type/infer the type of the RHS, but then if the return type is not a constant, the return
unwidened type is replaced by the type of the RHS.
```
inline val x: Int = 3
// typed as
inline val x: 3 = 3
```
0 commit comments