You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently cxx::UniquePtr<T> in Rust is equivalent to std::unique_ptr<T> in C++, which is sensible.
However, sometimes we know a particular UniquePtr is never supposed to be null:
mod ffi {extern"C++"{typeC;fncreate() -> UniquePtr<C>;// never supposed to be nullfnwith_ref(c:&C);}}
This ends up being inconvenient from the Rust side because every call to with_ref is going to do a nullness check as part of turning &UniquePtr<C> into &C to pass as the argument.
Some possibilities that would maybe be better:
Expose an optional second generic parameter on UniquePtr which declares non-nullability of the pointer.
extern"C++"{fncreate() -> UniquePtr<C,NonNull>;}
Such a pointer would be checked for null as part of the return, and subsequently not require any runtime check when derefing to &C.
This isn't great because currently we promise that none of our generated code involves any runtime checking. Maybe something with an attribute would be able to make it more obvious that the programmer is requesting a check.
Or, break the equivalence between cxx::UniquePtr<T> and std::unique_ptr<T> and declare that UniquePtr is non-nullable, requiring Option<UniquePtr<T>> if the programmer really intends a nullable one.
This isn't great either, because we want to build a real equivalency between corresponding types on either side of the language boundary, but it could turn out to be the least bad approach in this case.
The text was updated successfully, but these errors were encountered:
Perhaps we could define a NonNullUniquePtr<T> which has a corresponding non_null_unique_ptr<T> in C++.
There would be a runtime check for NULL when you construct the non_null_unique_ptr<T> but there would be no check as the value moves across the FFI boundary, so it would basically push the runtime check into the C++ code (maybe where it belongs).
Currently
cxx::UniquePtr<T>
in Rust is equivalent tostd::unique_ptr<T>
in C++, which is sensible.However, sometimes we know a particular UniquePtr is never supposed to be null:
This ends up being inconvenient from the Rust side because every call to
with_ref
is going to do a nullness check as part of turning&UniquePtr<C>
into&C
to pass as the argument.Some possibilities that would maybe be better:
Expose an optional second generic parameter on UniquePtr which declares non-nullability of the pointer.
Such a pointer would be checked for null as part of the return, and subsequently not require any runtime check when derefing to
&C
.This isn't great because currently we promise that none of our generated code involves any runtime checking. Maybe something with an attribute would be able to make it more obvious that the programmer is requesting a check.
Or, break the equivalence between
cxx::UniquePtr<T>
andstd::unique_ptr<T>
and declare that UniquePtr is non-nullable, requiringOption<UniquePtr<T>>
if the programmer really intends a nullable one.This isn't great either, because we want to build a real equivalency between corresponding types on either side of the language boundary, but it could turn out to be the least bad approach in this case.
The text was updated successfully, but these errors were encountered: