Source generate formatters as nested under the types they format for private member access #1745
Comments
|
Making it In line with this, the Analyzer should also be modified. |
|
As a mid-way solution that doesn't break existing users, it would be great to allow formatter to also work with |
|
@pikpok-lihhern you're right. But we're not going to support both modes. It's hard enough to support one. |
|
Yes, that's also fair. 🙂 Besides, it doesn't take a lot of work to upgrade the classes to partial for this to work anyway. 👍🏼 I'm looking forward to this as it will be very useful for how we setup our immutable data models. Much better than managing a constructor with a long list of parameters. We've been avoiding the constructors approach and marking the properties with internal accessors, then before running MPC, we replace internals to public to trick MPC to generate the formatters. 😅 It's really gross, this is going to be a much better solution. |
|
Alternatively, you could use UnsafeAccessorAttribute for non-public members. |
|
That would be cool. But it requires .NET 8+, which leaves most existing .NET code unsupported. In a few years maybe that approach will make sense. |
|
I've begun work on this. |
As the formatter must have access (per C# rules) to the private members, the formatter must be nested under the data type. This requires the data type (and any nesting types of that data type) to be declared as `partial` so that the source generated code can add the formatter as an `internal` member of it. Since traditionally data types haven't been required to be partial, we only nest the formatter under the data type when private members must be serialized; otherwise we continue to generate the formatter as nested under the generated resolver. Closes #1745
As the formatter must have access (per C# rules) to the private members, the formatter must be nested under the data type. This requires the data type (and any nesting types of that data type) to be declared as `partial` so that the source generated code can add the formatter as an `internal` member of it. Since traditionally data types haven't been required to be partial, we only nest the formatter under the data type when private members must be serialized; otherwise we continue to generate the formatter as nested under the generated resolver. Closes #1745
AOT formatters cannot access private members of the types they format today.
This is a blocker for "always on" AOT source generation of MessagePack serializable types.
As a solution, I propose that we generate formatters as nested types within the types that they format. This would be a substantial breaking change for existing users because they have to change their type declarations to be
partial. To minimize this, we should only generate the formatters as nested when they need to accessprivateorprotectedmembers. For all-publicformatters, they can remain as nested types under the source generated resolver.@pCYSl5EDgo shared some code to help us get this right, since nesting formatters under the type to be formatted may require multiple levels of nesting, for a variety of types all the way up to the namespace (which may or may not be there itself).
The text was updated successfully, but these errors were encountered: