Intrinsic object Type (#12501)

Can't be an object-type (in terms of how the spec/compiler defines object types).
This is more like a primitive.

• Don't want it to be assignable to any other primitive.
• Will have an apparent type of Object.
• Anything is assignable to {} (and almost anything is assignable to Object).
  • So object should be assignable to {} and Object.
  • What about Function?
    • Hesitance about agreement.
    • Saying "no" means you can never pass in anything with a call signature.
    • But functions are objects.
    • Does it have it in its prototype?
• This is "cheatable" construct (i.e. number -> Number -> object).
  • Yes, but this largely an intent-based construct.
    Covers a majority of the use-cases.
• What about people who want to ensure that you are an object with some set of optional properties?
  • People may write object & { a?, b?, c? }.
    • And subsequently type ObjectOf<T> = object & t.
    • Nobody will figure that out.
      • Well someone absolutely will, and why shouldn't they do this?
  • But implementing weak types would avoid some of the issues with this.
  • Are we implementing weak types?
    • Potentially.
      • Well then people are going to write this!
  • Kind of unfortunate that when people write { a?, b?, c? } they truly do mean they only want an object-type.
• A lot of the ideas being discussed at this meeting have to do with weak types, exact types, etc.

Conclusion:

• 👍 for object, still need to think about exact types.
• Current PR needs some changes, let's work with @HerringtonDarkholme to get that done.

Excess Property Checks on Union types (#12745)

Is a pretty complex problem.

• Currently we disable excess property checks for intersections and unions.
  • Why intersections?
    • Nobody is sure. We just did it?
      • Let's not do that.

#12904

• This is not excess property checking, this is weak type checks.
• Some of the conversation here has to do with the idea of flattening intersections of solely object types.
  • But makes inference problematic.
    • But it doesn't quite work with object literals anyway.
    • Still happens in other places.
  • We could create a type that knows about its originating type (i.e. a special object type that knows about its original intersection type).

Options:

• Union type property checks

• Weak types

• Exact types

• If we did exact types

  • Could you write exact interfaces?
  • How does it play with intersections?
  • Could you have an exact type parameter? What does it mean to have a generic exact type?

• If we did weak type detection

  • A heuristic.
  • Will likely catch a good class of bugs.
  • But doesn't quite have the full power of an exact type.

Freshness Maintenance for Object Spread (#12717)

• Is there any reason why we shouldn't do it?
• No.
• Seems like a bug.
• Let's do it
• Wait.
• Ehhh.
• But.
• Actually.
• It's arguable.

Conclusion: No.

(Reason: freshness checking was to catch issues for things like options bags - this sounds more like a potential case for exact types)