Now, that I completely understood how shared data works, I ran into the second most annoying thing. Maybe I don't get it either, so I'll just say what i find wrong and ask how can it be dealt with.
I'm making a system, which converts a given class into a typeless callback handler by scanning it's non-static shared methods and storing their delegates in a single place. The (rather slow) prototype uses Variant (no performance-critical code would be stupid enough to use Variant) to store statically typeless data (return value and the parameters). I cast away the exact type of the delegates and store it in a struct along with TypeInfo objects for the return type and the parameters (because the TypeInfo for delegates is broken and it doesn't contain info about parameters). I put a template opCall in this struct, which takes variadic parameters and packs them into an array of variants to pass to the callback, performing an optional type-check and synchronization. The struct is intended to wrap shared class or struct methods in a uniform type-safe, thread-safe dynamically typed wrapper to be used in modular architecture, where modules are arrays of such structs. In order for this struct to make any sense, i need to make it shared, so it's opCall can be called from across thread boundaries (which was the whole point). But if I make the struct shared, that means, I need to make TypeInfo objects shared as well, which is impossible, because there's no way to obtain a shared TypeInfo. Another attempt to make the struct immutable (it really is immutable by it's nature) also failed, because none of TypeInfo's methods (including the toString, which i use almost exclusively) are accessible. My question is: Why isn't TypeInfo immutable? It doesn't make any sense to have a mutable type info. Besides, Being immutable also means being shared (it also doesn't make any sense to have thread-local TypeInfo).