Make inline vals transparent

[nicolasstucki]

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

[sjrd]

I don't think I buy the "align with defs" argument. You can already achieve the equivalence with a def that returns a literal type, which is what the val does:

inline val x = 3
inline def x: 3 = 3

The argument for Byte and Short is somewhat interesting, but to me still feels like a workaround for the fact that we don't have literal Bytes and Shorts, and hence no literal types for them.

So overall I'm not in favor of this change.

[nicolasstucki]

@sjrd then there is a second question. Should it work like this if we explicitly write a transparent inline val?

transparent inline val x: Int = 3

Or should transparent val be disallowed or ignored?

[sjrd]

It shouldn't be ignored. Either forbid it, or make it work like you described. If have no strong feeling between those two options.

[nicolasstucki]

To forbid or support it, we need to be able to know it was transparent. But as we drop the transparent modifier when we desugar we do not have any way to know if the definition is transparent or not. As I argued many times we should keep this information, we did not do it to use up flags.

[odersky]

I have not seen a strong reason to change what we have here. It makes things more complex for no apparent gain.