Comment by anonymars
3 months ago
For me it was less not really about the opt-in part (after all, Newtonsoft works the same way) and more about stupid things like setting a name (DataMember), Enums, and in fact opting out (IgnoreDataMember)
It's especially annoying in libraries because the consumer might not even be using System.Text.Json, but you have to pull in the library anyway to apply its own attributes if you want it to work right. Just an overall awful smell given the existence of first-class framework attributes to do the same thing to avoid just that problem
Case in point: https://github.com/dotnet/efcore/pull/28084/files
> but you have to pull in the library anyway
That library is also out-of-the-box in the BCL in .NET > 5, though. It's not an extra install (except for projects stuck in .NET 4.x).
I get the desire to avoid that sort of redundancy in the BCL itself, but also explicit is better than implicit, which was the baseline theory for why System.Runtime.Serialization was the way it was even as it added more and more implicit "conventions", and if System.Text.Json supported the SRS attributes out-of-the-box there would be just as many complaints about "implicit magic" or it not following WCF conventions hard enough and that making it harder to migrate things using SRS attributes when you wanted different behavior in JSON serialization than you would want in WCF SOAP serialization. SRS has too much WCF baggage, unfortunately for all of us.
Perhaps what's left of the disagreement here between us is if System.Text.Json counts as "first-class framework attributes" and it certainly seems that way to me in .NET 5+, and especially as we celebrate the release of .NET 10. It's a small redundancy in the BCL, but it's still just "as BCL" and "first-class".