RFC: Fix an unsoundness issue around stripping optional properties

[asajeffrey]

Two RFCs that combine to fix an unsoundness issue with table subtyping.

[Nolan-O]

I find it strange that { p: number } is considered a sealed type at any point in time. Adding any new indices to a table of that type will not pass typechecking unless done at declaration, and it seems that accessing the field in any way later will cause the declaration to not typecheck:

Could we not just evaluate this to an unsealed type? It was my understanding before testing this that the only way to declare sealed types is to provide a type of an indexer, and any specific keys in a type will make it sealed

[asajeffrey]

.Could we not just evaluate this to an unsealed type? It was my understanding before testing this that the only way to declare sealed types is to provide a type of an indexer, and any specific keys in a type will make it sealed

User-supplied type annotations are always sealed. Type inference seals tables when they are returned from functions. (We should also be doing alias analysis to ensure unique access to unsealed tables, but that's another story.)

[zeux]

Just a process note... we should probably use one RFC per PR. When two orthogonal features are submitted as one PR, it makes it impossible for us to merge one but not the other. When the features are coupled and must come together, they should ideally come as a single .md file. I'd recommend merging the .md files in this case, especially since they reference each other. (I understand that the RFC proposes two separate changes to the type system but since they both need to happen I think it's better to have fewer .md files and have 1-1 relationship).

[asajeffrey]

These really are different (but related) features, I'd like to keep them as two md files. I'll split into two PRs if you like.

[zeux]

Can we at least remove cross-referencing then? Making all table literals unsealed seems to stand on its own at least.

[zeux]

One downside to avoiding sealing non-empty table literals is that it leads to typos in assignment being difficult/impossible to detect:

local t = {x = 1, y = 2}
if foo then
t.z = 3 -- is z a typo or intentional 2-vs-3 choice?
end

Which I suppose is why we're sealing them currently. Of course it's unclear what to do about this in absence of type annotations or record types, so it's probably fine - the code above could easily be valid or invalid depending on the intent. My understanding is that we will still detect uses of keys that were never written to.

[asajeffrey]

Yes, not much we can do about that though. I'll add this point to the downsides section.

[asajeffrey]

I removed the cyclic cross-referencing, so the subtyping proposal refers to the table literals proposal, but not the other way round.

[alexmccord]

Control flow analysis will be able to keep an eye on properties that are definitely-or-maybe assigned. The same problem still arise even when the tables are empty anyway regardless of this RFC.

local t = {}
if cond()
  t.x = 5
end

local some_number: number = t.x