autowrap
autowrap copied to clipboard
symmetryinvestments
Can't wrap functions that return pointers to structs that can't be wrapped
struct Uncopiable {
@disable this(this);
double x;
}
export auto uncopiablePtr(double d = 33.3) {
return new Uncopiable(d);
}
Calling this from python:
assert uncopiable_ptr(33.3).d == 33.3
Yields:
RuntimeError: D conversion function d_to_python failed with type issues.Uncopiable*
Uncopiable isn't wrappable due to not being copiable, and as such it's not registered.
Okay so you specifically disable registering uncopyable structs because I asked you to so we could have the thing compiling. That's no longer necessary and I deleted the check on my branch. You just need to avoid registering methods that cause problems like opAssign and possibly constructors. Also it failed for dumb reasons because it got confused by the __ fields. Just don't try to wrap those - see my branch.
A pointer to a noncopyable struct should be fine - in fact if you can't copy it deal with a refcounted pointer to it. Pyd does ref counting automatically. Y
Maybe autowrap should have a way to have a type registered by reference. A raw pointer is hairy - who knows who owns it or where it came from.
You just need to avoid registering methods that cause problems like opAssign
This is done since yesterday.
possibly constructors
No, otherwise it wouldn't be possible to create objects from Python.
Also it failed for dumb reasons because it got confused by the __ fields
Fixed yesterday.
A pointer to a noncopyable struct should be fine
It should. However, pyd doesn't accept non-copyable structs so we can't register it.
Maybe autowrap should have a way to have a type registered by reference
pyd doesn't have a way to register by reference that I know of, so there's not much autowrap can do.
A raw pointer is hairy - who knows who owns it or where it came from.
Unless stated otherwise, it's GC allocated and so ok. If it's not GC allocated it probably shouldn't be a raw pointer.
Can we wrap non-copyable structs as private members in classes and use std.typecons.Proxy to forward everything? Or will pyd still choke on the non-copyable private member?
@John-Colvin I'd have to try, I don't know. And why std.typecons.Proxy instead of alias this?
Not all objects need to be created from python btw. Sometimes you just need to be able to handle the result of calling D.
You can register a Wrapper!T where it's beneath that a pointer and give Python access to same fields and methods (using getters and setters if fields not possible) as underlying type has.