HeapObject *swift_reallocObject(HeapObject *, size_t)
should be a Swift runtime entry point. The runtime should be responsible for knowing whether an object's address is significant at runtime. The caller is still responsible for guaranteeing that the object contents are bitwise takeable.
One of the runtime checks will be for be for the existence of associated objects. @Arnold points out that it could be a slow check because the ObjC runtime doesn't have a fast entry point yet. If that's the case, we have a few options for proceeding:
-
Keep this API underscored for now, and comment that users of the API need to guarantee their ManagedBuffers aren't exposed to ObjC.
-
Add a compiler attribute that can be used in ManagedBuffer's definition to that prevents the runtime from allowing associated objects. The runtime support exists, but the compiler needs to be taught to initialize a metadata bit for that attribute.
-
File a bug against the ObjC runtime to add a fast "hasAssociatedObject" check callable from the Swift runtime. (/cc @gparker42)
Which of these options to pursue probable depends on your timetable for using the API and whether the measured performance overhead of the associated object check is unacceptable to you.