Const holds a type rather than a value

[Morriar]

Follow up on #408 (comment).

In the context of an RBI file, does it really make sense to hold the value of constants?

This PR proposes to change Const so it only stores the type we find a the T.let if any.

So this:

A = 42
B = T.let(42, Integer)
C = foo(T.let(42, Integer))

gives this:

A = T.let(T.unsafe(nil), T.untyped)
B = T.let(T.unsafe(nil), Integer)
C = T.let(T.unsafe(nil), T.untyped)

This is quite a breaking change for the gem's API and should be released with at least a minor version bump.

I think we can apply the same logic to optional positional and keyword parameters 🤔

[KaanOzkan]

Do we consider RBI files as documentation? Could this be a confusing change?

[st0012]

Also, will this create huge RBI changes when it's adopted by Tapioca?

[Morriar]

Do we consider RBI files as documentation? Could this be a confusing change?

From RBI files what we really care about is the type (and accessorily the comment since we also extract it). I'm not sure the value as that much importance when it comes to document behaviour especially if the value is not a literal.

will this create huge RBI changes when it's adopted by Tapioca?

If you mean diff, yes. If you means API change for Tapioca to use it? Less.

[st0012]

Given it's a breaking change, can the description also include the benefits it will bring too?

[paracycle]

I don't think this is a breaking change at all. The fact that we were including actual constant values in RBI files wasn't intentional and there should be nothing that relies on then being there.