RFC: New name for strictOptionalProperties

[RyanCavanaugh]

Per discussion at #44421 and #44524, we're moving the flag currently named strictOptionalProperties out of the strict family and into the off-by-default category inhabited by other options like noImplicitReturns, noUncheckedIndexedAccess, and allowUmdGlobalAccess

As such, we need a new name for this. As a refresher, the flag makes it so that a property that is optional, e.g. { x?: string }, cannot be initialized with the actual value undefined, e.g. someObj.x = undefined. If this flag is not set, then today's behavior of allowing undefined values to be assigned into optional properties remains. There is no effect on parameters.

Please only post name suggestions (one per comment) and votes; actual discussion on the flag should remain at #44421. Happy coding!

[fatcerberus]

There is no effect on

I don’t think you finished this sentence… 😉

[RyanCavanaugh]

Thanks, fixed 😅

[fatcerberus]

strictOptionalProperties is such a perfect name, I can’t think of anything better. noExplicitUndefinedForOptionalProperties maybe, but that’s really verbose and also maybe misleading since you can still declare properties as being in a union with undefined…

[aleph-naught2tog]

noExplicitUndefinedValuesForOptionalProperties

[fatcerberus]

Yeah, that has the same problem I mentioned in that you could still declare the property as e.g. foo?: string | undefined…

[RyanCavanaugh]

noImplicitPropertyUndefined

[johnnyreilly]

noUndefinedOptionalProperties

[Faithfinder]

noImplicitUndefinedInOptionals

[kungfusheep]

noExplicitUndefinedOptionals

[aleph-naught2tog]

noOptionalsInitializedWithUndefined

[aleph-naught2tog]

noInitializingOptionalPropertiesWithUndefined

[fatcerberus]

For the people who thumbs-downed my comment: That wasn't an opinion, I was simply pointing out that even with SOP turned on, this is still allowed:

interface Foo {
    foo?: string | undefined;
}

let x: Foo = { foo: undefined };

...which is why I can't come up with a good name for the flag other than the one it already has, and why I don't like the noExplicitUndefined variants.

[DanielRosenwasser]

noExplicitUndefinedInOptionals

[LukeNotable]

I'm not following the noExplict proposals: the option is whether to add an implicit | undefined when declaring { foo?: Bar } and thus getting { foo?: Bar | undefined }.

noImplicitOptionalPropertyUndefined

[bodograumann]

distinguishMissingFromUndefined

Cf. #13195

[fatcerberus]

Alternatively: stricterOptionalProperties. It’s “too strict” for strict (therefore stricter) but still tightens up the type system.

[tjjfvi]

pedanticOptionalProperties

[fatcerberus]

@MartinJohns I'm not sure why you're confused about my comment?

[softwareCobbler]

noImplicitUndefinedInOptionalProperties

[fson]

distinctUndefinedAndOptionalProperties

[RyanCavanaugh]

Thanks for the ideas, everyone - this really got us thinking. Not sure if Daniel is posting notes so here's my recollection from memory.

• We didn't like the noExplicit variants because it implies that it's a switch to ban x?: T | undefined, when really it's the opposite
• The noImplicit variants were OK; noImplicitUndefinedInOptionalProperties is by far the clearest name but is longer than our next-longest commonly-used flag noUncheckedIndexedAccess by quite a few characters
• Names that implied stronger guarantees were rejected because optional properties are still unsound through 2-hop assignments
• (much noodling is had, along with sadness that we can't really put this in strict)
• exactOptionalPropertyTypes was floated and was met with universal lack of dread, which made it a strong contender
  • Implies a possible future exact family, though we're by no means roadmapping that
  • Does what it says on the tin: The type of an optional property is exactly what you wrote, not that type plus undefined

PR up at #44626