Support rust Option and C++ std::optional

[fbeutel]

It would greatly simplify API development if automatic Option<T> conversion was supported.

Since C++17 there is std::optional<T>, which would allow a more or less direct translation of supported types.

I had a look at #67 and the ideas and work done by @myronahn for Vec seems to be similar to what would be needed for supporting Option so maybe one could build on that...

[philipcraig]

I'm trying an implementation of this, following the code patterns for Vec and CxxVector

[philipcraig]

#44 is required for this, along with an extra flag_if_supported("/std:c++17"), which I will add in the PR for this issue. Otherwise the MSVC compiler complains:

The contents of <optional> are available only with C++17 or later.

[philipcraig]

Most work needed for this is clear. I can follow the RustVec and CxxVector work.

There is one difference between the already-supported types like Box, Vec and String that I'm not sure how best to tackle -- the already-supported types offer a function to get a (sometimes mut) pointer to the underlying contents, such as as_mut_ptr(). Rust Option doesn't.

So, for example, we have:

cxx/macro/src/expand.rs

Line 260 in 32439da

Type::RustVec(_) => quote!(#var.as_mut_ptr() as *const ::cxx::private::RustVec<_>),

and similar lines for other types nearby. @dtolnay @fbeutel have you any thoughts on how this should be handled for the RustOption type that needs to be implemented?

[dtolnay]

We don't use Vec::as_mut_ptr. That line is calling MaybeUninit::as_mut_ptr.

[sbrocket]

@philipcraig Are you still planning on working on this, or could you use help? I'm finding myself in a situation where I could really use Option, for a result-like type on an interface.

[philipcraig]

Hi @sbrocket, I got stalled when I realised late on that there is not a fixed repr for Rust Option, so that we will have to copy bits. It should all be doable but my approach needs to be thrown away and re-done. In short, if you would like to tackle it, please do.

My work in progress is at https://github.com/philipcraig/cxx/tree/support_option_and_std_optional. It doesn't build and has the wrong assumptions about the repr of rust Option, but some of it may be useful

[adetaylor]

when I realised late on that there is not a fixed repr for Rust Option

rust-lang/rust#75454 if you hadn't come across it.

[Timmmm]

I'd be happy with a solution that always copies initially.

[JanKaul]

I would like start the discussion again how a sharable Option type could be implemented. The problem with Rust's Option seems to be that the memory layout is not stable.

How about using an custom option type with repr(C, u8) like so:

#[repr(C, u8)]
pub enum CxxOptional<T> {
    None,
    Some(T),
}

This has the advantage that it is still a rust enum but it has a defined memory layout. Moreover, it should have the same memory layout as std::optional. According to the rust representation doc this is equivalent to:

#[repr(C)]
struct CxxOptionalRepr {
    tag: CxxOptionalDiscriminant,
    payload: CxxOptionalFields,
}

// This is the discriminant enum.
#[repr(u8)]
enum CxxOptionalDiscriminant { None, Some }

// This is the variant union.
#[repr(C)]
union CxxOptionalFields<T> {
    None: Dummy,
    Some: T
}

#[repr(C)]
struct Dummy;

The corresponding C++ type looks like:

struct CxxOptional{
  enum class Tag {
    None,
    Some,
  };

  struct Some_Body {
    T _0;
  };

  Tag tag;
  union {
    Some_Body some;
  };
};

The tag field is of type unsigned char which should make it equivalent to std::optional which uses a bool. This should work because c++ interprets 0 as false and every other number as true.

What do you think about it?

[JanKaul]

Sadly, it turns out that the fields of std::optional are arranged the other way around:

struct optional{

  union {
    T some;
  };
  bool _engaged;
};