Skip to content
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

Make it more ergonomic to make external types serializable #346

Open
aradalvand opened this issue Nov 1, 2024 · 1 comment
Open

Make it more ergonomic to make external types serializable #346

aradalvand opened this issue Nov 1, 2024 · 1 comment

Comments

@aradalvand
Copy link

aradalvand commented Nov 1, 2024

Today, if you have an external type (that you obviously can't annotate with [MemoryPackable]) that you want to serialize using MemoryPack, you fall off cliff where you basically have to resort to using a wrapper type + a custom formatter + register that formatter + annotate every property of that type with [MemoryPackAllowSerialize] wherever it appears.

This is clearly not the best developer experience, especially as contrasted with a simple [MemoryPackable] attribute.

I'd propose introducing an assembly-level attribute that allows users to instruct MemoryPack to generate a serializer for an external type + automatically register that in some static context using [ModuleInitializer] + have it be recognized as a memory-packable type everywhere (meaning no need for a gazillion [MemoryPackAllowSerialize]s everywhere — you can then use cutting-edge features like [UnsafeAccessor] (if necessary, to write to/invoke private properties/constructors) to source-generate serializers with no perf overhead.

Example:

[assembly: MemoryPackable<SomeExternalType>]
@aradalvand
Copy link
Author

aradalvand commented Nov 2, 2024

Update: Could potentially be closed in favor of #347 (if you think this is too much) which I think is a simpler/less controversial alternative.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant