-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
Closed
Tracked by
#100159
Labels
Milestone
Comments
eiriktsarpalis
added
the
api-suggestion
Early API idea and discussion, it is NOT ready for implementation
label
Mar 21, 2024
Tagging subscribers to this area: @dotnet/area-system-text-json, @gregsdennis |
dotnet-policy-service
bot
added
the
untriaged
New issue has not been triaged by the area owner
label
Mar 21, 2024
eiriktsarpalis
added
api-ready-for-review
API is ready for review, it is NOT ready for implementation
and removed
api-suggestion
Early API idea and discussion, it is NOT ready for implementation
labels
Mar 21, 2024
eiriktsarpalis
added
api-suggestion
Early API idea and discussion, it is NOT ready for implementation
and removed
untriaged
New issue has not been triaged by the area owner
api-ready-for-review
API is ready for review, it is NOT ready for implementation
labels
Mar 21, 2024
This was referenced Mar 21, 2024
eiriktsarpalis
changed the title
[API Proposal]: Add a STJ feature flag treating non-optional constructor parameters as required
Add a STJ feature flag treating non-optional constructor parameters as required
Mar 22, 2024
9 tasks
eiriktsarpalis
added
blocking
Marks issues that we want to fast track in order to unblock other important work
api-ready-for-review
API is ready for review, it is NOT ready for implementation
and removed
api-suggestion
Early API idea and discussion, it is NOT ready for implementation
labels
Apr 23, 2024
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);
} |
bartonjs
added
api-approved
API was approved in API review, it can be implemented
breaking-change
Issue or PR that represents a breaking API or functional change over a prerelease.
and removed
blocking
Marks issues that we want to fast track in order to unblock other important work
api-ready-for-review
API is ready for review, it is NOT ready for implementation
labels
Apr 23, 2024
dotnet-policy-service
bot
added
the
needs-breaking-change-doc-created
Breaking changes need an issue opened with https://github.com/dotnet/docs/issues/new?template=dotnet
label
Apr 23, 2024
Added
Tagging @dotnet/compat for awareness of the breaking change. |
eiriktsarpalis
removed
breaking-change
Issue or PR that represents a breaking API or functional change over a prerelease.
needs-breaking-change-doc-created
Breaking changes need an issue opened with https://github.com/dotnet/docs/issues/new?template=dotnet
labels
Jun 5, 2024
Similar to nullability annotations, we're reverting this to be an opt-in feature hence it no longer constitutes a breaking change. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Labels
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: