JSON needs object initializer equivalent APIs

[krwq]

Recently C# has added two features which rely on the object initializer syntax:

• init-only properties
• required keyword

In the current state JSON reflection APIs can ignore the fact that property is init-only and still set it and required constraint is not enforced. For source-gen on the other hand regular setter code simply won't compile and similarly for required properties constructor will cause compile errors.

We should:

• update the contract model to allow for such construction - most likely this will be the same work as Add support for parameterized constructors in System.Text.Json contract customization (converters) #71944
• update source-gen code to use those APIs for init-only/required properties - this will likely need rather major refactoring of source-gen code which currently uses reflection APIs (reflection implementation over Roslyn APIs) which is missing a way to check if property is required - we will likely need to change it to use Roslyn APIs directly
• possibly, adjust reflection code to behave consistently with source-gen

One way to solve this problem is to treat init-only and required properties the same way as arguments to parametrized constructor, then passing them to parametrized constructor assigns them in the object initializer.

Relevant issues:

• System.Text.Json source generator fails to deserialize init-only & required properties #58770
• Ensure JsonSerializer / source generator works well with required members #70945
• Add support for parameterized constructors in System.Text.Json contract customization (converters) #71944
• System.Text.Json can't deserialize type with more than 64 ctor parameters. #71984
• System.Text.Json does not support constructors with byref parameters. #46088

[ghost]

Tagging subscribers to this area: @dotnet/area-system-text-json, @gregsdennis
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Recently C# has added two features which rely on the object initializer syntax:

• init-only properties
• required keyword

In the current state JSON reflection APIs can ignore the fact that property is init-only and still set it and required constraint is not enforced. For source-gen on the other hand regular setter code simply won't compile and similarly for required properties constructor will cause compile errors.

We should:

• update the contract model to allow for such construction - most likely this will be the same work as Add support for parameterized constructors in System.Text.Json contract customization (converters) #71944
• update source-gen code to use those APIs for init-only/required properties - this will likely need rather major refactoring of source-gen code which currently uses reflection APIs (reflection implementation over Roslyn APIs) which is missing a way to check if property is required - we will likely need to change it to use Roslyn APIs directly
• possibly, adjust reflection code to behave consistently with source-gen

One way to solve this problem is to treat init-only and required properties the same way as arguments to parametrized constructor, then passing them to parametrized constructor assigns them in the object initializer.

Relevant issues:

• System.Text.Json source generator fails to deserialize init-only & required properties #58770
• Ensure JsonSerializer / source generator works well with required members #70945
• Add support for parameterized constructors in System.Text.Json contract customization (converters) #71944
• System.Text.Json can't deserialize type with more than 64 ctor parameters. #71984

Author:	krwq
Assignees:	-
Labels:	area-System.Text.Json, User Story, Cost:XL
Milestone:	8.0.0

[jkotas]

(reflection implementation over Roslyn APIs) which is missing a way to check if property is required

The reflection object does allow you to check whether the property is required by looking for System.Runtime.CompilerServices.RequiredMemberAttribute.

[eiriktsarpalis]

We might want to address this in combination with #71944.

[eiriktsarpalis]

Fixed in #83147. Any outstanding work is tracked by the issues linked in the description.

[amis92]

So it's completed, but still in Future milestone - that's intentional?