-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add a STJ feature flag treating non-optional constructor parameters as required #100075
Comments
Tagging subscribers to this area: @dotnet/area-system-text-json, @gregsdennis |
namespace System.Text.Json;
public partial class JsonSerializerOptions
{
public bool RespectRequiredConstructorParameters { get; set; } = AppContext(true);
}
namespace System.Text.Json.Serialization;
public partial class JsonSourceGenerationOptionsAttribute
{
public bool RespectRequiredConstructorParameters { get; set; } = AppContext(true);
} |
Added
Tagging @dotnet/compat for awareness of the breaking change. |
Similar to nullability annotations, we're reverting this to be an opt-in feature hence it no longer constitutes a breaking change. |
Background and motivation
System.Text.Json constructor-based deserialization currently treats all constructor parameters as optional, as can be highlighted in the following example:
This can create unexpected validation problems since users typically think of non-optional parameters as required values in the object contract. It typically also results in deserialized properties violating their own nullability annotations. Another problem is that it could result either in discrepancies or overly verbose outputs in components that are attempting to derive a JSON schema from the STJ contracts.
Changing this behavior would most likely constitute a serious breaking change, so we would instead like to expose a feature flag that opts in to new behavior, marking non-optional constructor parameters as required. Rather than making this an application-wide feature switch, this should instead be a per-
JsonSerializerOptions
setting to avoid breaking third-party components making use of STJ.Related to #1256
API Proposal
API Usage
Alternative Designs
This proposal is very closely related to #100144. We should consider a design that unifies both behaviors under a single feature switch.
Risks
No response
The text was updated successfully, but these errors were encountered: