Flow: Configuration for Strict Object Types as default behavior

[jedmao]

First, thanks for implementing Strict Object Types and I hope that Object type spread in #1326 gets implemented as well.

In response to my frustrations and @cpojer's tweet that exact object types, "should be your new default," can we talk about how to "actually" make it a default?

Would it be unreasonable to request an option in .flowconfig to enable this as the default behavior?

The biggest obstacle I can imagine is the inability to intersect exact object types (#2626), but that could be resolved by allowing us to intersect exact object types w/o a spread operator, wouldn't it?

I'm eager to come up with a viable solution.

[conartist6]

By intersect exact object types _without_ a spread operator, do you mean merge exact object types _with_ a spread operator?

[jedmao]

@conartist6, no. I mean w/o a spread operator, since a spread operator implies that the 2nd spread would override the 1st spread, which wouldn't throw an error. I want the error, not the spread functionality. Thanks for asking for clarification.

[adamjernst]

We'd also need to have a syntax for inexact object types (or I suppose you could just flip it, so that {|...|} means inexact).

[jedmao]

Relevant to this issue: https://github.com/facebook/flow/issues/2626#issuecomment-290107574

[STRML]

I pretty much never want to use inexact object types. They have rather bizarre behavior, especially with spreads (#3534). How about a config option and {? foo: string ?} (or just $Inexact<{foo: string}> for the old behavior?

[vkurchatkin]

@STRML inexact objects are better for everything else, though. Also most often spread is used with object literals, which are exact by default.

[STRML]

Perhaps it's personal preference - I find myself wanting to exactly specify every type I use so I don't say, accidentally fat-finger an optional property. So I'd be very happy to have it as a default, although I think we'd run the risk of breaking external libdefs with it.

[vkurchatkin]

I don't say, accidentally fat-finger an optional property

This is a separate issue though. I think it could be solved by flow cover in the future.