Automatically support `functools.cached_property` without requiring setting `dict=True` about msgspec HOT 2 OPEN

Upon further investigation, I'm now leaning more towards 3.

• Some of the preprocessing we'll need to do to make this work will also be needed to support #573.
• Providing builtin support for this will avoid the need to allocate a __dict__ per instance, reducing memory usage somewhat and slightly accelerating attribute access
• Likewise, handling this ourselves lets us backport the 3.12 fix to avoid usage of an RLock per cached property, which can provide unnecessary lock contention in threaded applications.

The main downsides are:

• More code on our end
• Some magic. When used on a Struct type, the cached_property implementation itself won't ever actually run, it's just a decorator flag to tell the Struct implementation to treat it as a cached property using our own implementation. Since attrs is already doing the same, I feel better following their lead.

from msgspec.

• Some magic. When used on a Struct type, the cached_property implementation itself won't ever actually run, it's just a decorator flag to tell the Struct implementation to treat it as a cached property using our own implementation. Since attrs is already doing the same, I feel better following their lead.

What about not using functools.cached_property, but instead provide e.g. msgspec.cached_property, which would work the same way you described, but would make it more explicit that this is not the same as the functools one? That would eliminate the magic aspect of it while providing the same functionality.

from msgspec.