Clean up record_representation type

[DZakh]

Yet another clean up PR to better familiarize with the codebase

[cristianoc]

I think changes to the internal representation of types might be problematic for the editor extension (which vendors the compiler).
@zth right?

[cknitt]

Is the has_optional really needed or couldn't we just match on the optional_labels themselves`?
I am worried it might lead to inconsistent state.

[DZakh]

I think changes to the internal representation of types might be problematic for the editor extension (which vendors the compiler).

Could you explain which changes are acceptable and how it is related to the editor extension?

[DZakh]

Is the has_optional really needed or couldn't we just match on the optional_labels themselves`? I am worried it might lead to inconsistent state.

Hmmm, I think then it's better to keep the type as it was before :)

[cristianoc]

I think changes to the internal representation of types might be problematic for the editor extension (which vendors the compiler).

Could you explain which changes are acceptable and how it is related to the editor extension?

See 0a60758#diff-bf8a7b89f35f42262078976d00e99dd1aa6e3bbd7b981b44d48cf50a31af9541

[zth]

I think changes to the internal representation of types might be problematic for the editor extension (which vendors the compiler). @zth right?

Correct. I replied in the other thread too, but in short - we can't change the runtime representation as of now before we have tooling that's versioned with and tied to the compiler version itself. Which isn't the case right now.

As for what would change runtime representation, @cristianoc knows that much better than me.

[DZakh]

It's not relevant then. Even though I close the PR, an explanation on what changes the runtime representation would help