Windows Terminal version: 1.3.2382.0

Related to...

• Add test for null Profile.StartingDirectory #7423: missing test for nullable startingDirectory
• Make Profile a WinRT object #7283: winrt-ify Profile

Some settings in Profile are std::optional and others aren't. This leads to an inconsistent handling of setting the property to null in the JSON. Consider the following examples:

1. "backgroundImage" (std::optional<std::wstring>)
   • explicitly do not have a background image
2. "snapOnInput" (bool)
   • fall back to profiles.defaults value
3. "startingDirectory" (std::optional<std::wstring>)
   • inherit the startingDirectory of the parent process
4. "commandline" (std::wstring)
   • fall back to profiles.defaults value

From an implementation standpoint, it makes sense. std:optionals treat null as a meaningful value, whereas non-std::optionals treat null as fall back.

The problem here is 2-fold:

1. The schema does not always accept null as a value, even though we do
   • startingDirectory is particularly an example of this where it has a unique behavior from null but is not in the schema
2. A user has no way of knowing whether setting a profile setting to null will consistently fallback or set the value.

Proposed Implementation/Solution

Make none of the profile settings nullable. If the user...

• omits the setting --> fall back
• sets to null --> validate a potential type mismatch

We should also add a special enum value for startingDirectory to inherit from the process.

From a Settings UI standpoint, it won't be possible to set settings to null either. So we should just purge null-ness as an option, and add specific enums for special behavior. Fallback and other special behavior must be represented in the Settings UI as their own button/option.