Does .delete() on a return_value_policy::reference wrapper call the destructor?

[Eryx5502]

We use return_value_policy::reference() to return references to C++ member objects. We noticed that .delete() is still available on the JS wrapper, and we're unsure what it does.

Reproduction

#include <emscripten/bind.h>
#include <vector>
using namespace emscripten;

struct Inner { std::vector<float> data; };

class Owner {
    Inner m_inner{{1.0f, 2.0f, 3.0f}};
public:
    Inner& getInner() { return m_inner; }
};

EMSCRIPTEN_BINDINGS(example) {
    class_<Inner>("Inner")
        .function("size", optional_override([](const Inner& self) {
            return self.data.size();
        }));
    class_<Owner>("Owner")
        .constructor<>()
        .function("getInner", &Owner::getInner, return_value_policy::reference());
}

const owner = new Module.Owner();
const inner = owner.getInner();
inner.delete();                     // what happens here?
owner.getInner().size();            // still returns 3 — no crash
owner.delete();

What we observed

• inner.delete() marks the wrapper as deleted (isDeleted() → true)
• But the parent's member appears unaffected — no crash even after allocator pressure

What we expected from reading the source

We traced .delete() → releaseClassHandle → runDestructor → rawDestructor(ptr) which is delete ptr. Since ptr points to a member (not new'd), we expected this to be undefined behaviour. But it doesn't crash.

Questions

1. Does rawDestructor actually run for reference-returned pointers, or is there a guard we're missing?
2. If it does run, why doesn't delete on a non-heap pointer crash in WASM?
3. What is the intended contract — should JS never call .delete() on reference wrappers? Or is this .delete() only affecting the wrapper and it is safe to call it in the sense that it won't corrupt the original data structure?

[sbc100]

@brendandahl ?

[brendandahl]

delete should not be called on references. I'd need to look more into the guts of what actually happens when you call delete on a reference, but we should probably fix the core issue. I'm leaning towards having delete throw an exception when called on a reference. Alternatively, we could make it so references don't even have a delete method. If we did that though, we'd need a way to define the two types of class handles in TS which feels like a bigger change. I'm open to suggestions though.

[Eryx5502]

It possibly is a bigger change, but for me it makes more sense reference wrappers not having a .delete() method. Not very familiar with the codebase myself, nor with TS, so I can't be of any help on that. Maybe some sort of Deletable interface or abstract class that reference handles don't implement could do?

Otherwise, the thrown you mention could do, so that at least consumers know they shouldn't .delete().