Allow struct types to typecheck optional/unknown fields

[WillBAnders]

Currently, structs use structural subtyping which considers any struct to be a subtype so long as the required fields are present. This is insufficient for handling optional/unknown fields, which is an important part of type safety when working with structs (particularly when involving default values).

• Optional fields may be provided, but if so must typecheck successfully. It is unclear if there's an effective way to represent this with null such that users are not confused between required, nullable fields, optional, non-nullable fields (as with JSON). Maybe optional is handled differently for subtyping but accessing fields returns Nullable versions (properly wrapped for optional, nullable) ?
• Unknown fields are generally a concern for type safety, but could be useful for abstractions involving structs (such as transforming specific fields but leaving all others untouched). There are currently no plans to do any kind of more customizable [key: string] clauses as with TypeScript, just a general "all other fields".

[TheMaverickProgrammer]

I've had success using two meta types for this situation.

1. Type.Optional
2. Type.Unsolved

After analyzing the code a bit, it seems to me the best first attempt would be to create a new class type in the library for both as well.

Optional is essentially a sum-type containing a term of its inner-type (for example how it is handled in the List class), or None. I don't know the consequences of allowing None to pass equivalency checks for null in the expression None == null but it might be safe. Definitely worth exploring.

Unsolved on the other hand is much like your current Dynamic class implementation. Since your framework allows us to add fields, we could just introduce some new judgements to help Dynamic terms with meta-type unsolved become "solved" by simply removing this meta-type when the unification and judgements succeed.

Do you have any objections or concerns with this approach?

[WillBAnders]

I think most of my questions here are for userland behavior with language design as opposed to internal type checking.

1. The concern I have is that struct.nullable and struct.optional would both return Nullable<Value>. Introducing an additional Optional type such that struct.optional returns Optional<Value> instead is interesting (if I'm interpreting your idea correctly). I agree that it would definitely be preferable for struct.optional == null to be supported, which feels a bit wonky with that.

• There's a parallel with maps here as well: map["missing"] returns Nullable<Value>, so if the values themselves are nullable you get Nullable<Nullable<Value>> as the return type. But since struct values depend on the keys, this makes it more important to track what each key does. I suppose there's an option where struct.optional is invalid and struct["optional"] must be used to distinguish the two, but that feels arbitrary. Maybe this isn't as big as deal compared to TypeScript because in TS you get both null, required undefined, and optional returning undefined as behavior.

2. I'm not really sure what Unsolved is for in this scenario; I can't see the intent behind it. What problem is it trying to solve?

[TheMaverickProgrammer]

1. The interpretation is correct.

• Could your concerns be put to rest if the map["missing"] returns Optional<Value>::none?

2. It's a meta-type used in some solvers. I've made use of it as well. This was in reply to your mention of "unknown fields".

[WillBAnders]

So, just kinda kept writing and writing and this became basically a total thought drop over the design space here:

1. I think it becomes circular. It might be slightly more descriptive and help make sense of Optional<Nullable<Value>>, but if the map contains an Optional value you get Optional<Optional<Value>> which is roughly the same. There are two problems here, one with accessing values and the other with creating them:
   • For accessing values, you'd be able to make whatever combination of checks you need as shown below:
     • Map<String, Value>, map["key"]: returns Nullable<Value>:
       • map["key"] != null checks that the value is present
       • map["key"]?.method() invokes method on Value if present and coalesces the result
       • map["key"].present() checks the value is present (currently no method for this)
     • Map<String, Nullable<Value>>, map["key"] returns Nullable<Nullable<Value>>:
       • map["key"] != null checks that the value is present, as above
       • map["key"]?.value invokes the getter value on Nullable<Value> if present, coalescing toNullable<Value>
         • map["key"]?.value != null therefore checks that the value is present & not null
         • map["key"]?.value?.method() therefore invokes method on Value if present and coalesces the result
       • map["key"]?.present() == true checks only that the value is not null
       • map["key"]?.present() == false checks only that the value is null
     • The key observation here is that the result of map["key"] access (performing the lookup) can be used to disambiguate all possibilities safely (as would struct.optionalNullable). In TypeScript, object.field could be optional (undefined) or explicitly set to undefined. I think recognizing that this doesn't apply to Rhovas alleviates my concerns here - struct.optional is still a bit visually ambiguous on it's own, but unwrapping to the value gives struct.optional?.value which is more recognizable as a pattern.
   • Creating values is a bit trickier. Because {field: Nullable<Value>} and {field?: Value} are not the same type, the question becomes how do we create structs where the fields are actually optional? I think for that you need a new operator:
     • {field: value} creates {field: Value}
     • {field: nullable} creates {field: Nullable<Value>}
     • {field?: value} is invalid, as it would be the same as field: value if implicitly converted to Nullable
     • {field?: nullable} creates {field?: Value}.
     • This is a use case where I could see a separate Optional type come in handy as you wouldn't need unique syntax, but IMO the unique syntax here is probably clearer and avoids {field: nullable.to(Optional)} as a conversion (not to mention the aspects of multiple null types). But, maybe there's an advantage towards doing that with regards to JavaScript compatibility, and have Nullable w/ null and Optional w/ undefined. But, I do feel like that would make API design a lot harder to get right (and you still have the quirk of {field: Optional(optional)} to get {field: Optional} if needed.
2. That's in reference to this issue, so it's user-level and not an issue in type checking. What I'm imagining here is something like Struct<{x: Type, *}> to indicate a struct with additional fields for those use cases, thus making Struct<{x: Type}> be only {x: Type}. This allows for both and also avoids accidentally passing incorrect fields, e.g. {typo: String} to {type?: String}.