Rust type aliases

[schreter]

In #1181, I published a tentative implementation for Rust type aliases.

The problem to solve is the following: we have two bridges, one exporting the Rust type, the other declaring functions, which need to work with this type. Currently, one cannot express this, because trying to use the same type in the second bridge would fail, since RustType trait is already implemented. So we need a possibility to specify an alias.

The tentative implementation specifies the alias via type Name = ::path::Name, where Name must be same on both sides. That's somewhat bad, since ideal would be an use ::path::Name statement. However, use is not allowed in extern blocks.

The question: Do we want to allow use for Rust types on the bridge module level? Writing use ::path::Name at the bridge level would be idiomatic Rust and we could generate appropriate Rust type alias with checks and so on at that level, instead of misusing type syntax in an extern block for it.

Any other ideas how to express it?

Thanks.

[schreter]

@wvwwvwwv your opinion?

[wvwwvwwv]

This totally makes sense to me, since different modules/projects sharing the same data types are actually very common. Adding support for use ::path::Name is most preferable, but using an alias as you suggested looks also reasonable.

[futscdav]

Any chance of this being resolved soon? I'm trying to do the same thing, I can for now keep everything coupled inside of a single bridge as a workaround, but it introduces a lot of mental and technical overhead.

[schreter]

@futscdav

Any chance of this being resolved soon? I'm trying to do the same thing, I can for now keep everything coupled inside of a single bridge as a workaround, but it introduces a lot of mental and technical overhead.

I'm sorry, but since the maintainer doesn't have the interest to review anything beyond trivial fixes, react to issues/RFCs and/or establish a secondary maintainer since half a year, I gave up.

We have our own local copy of the crate which we maintain for our large project (8M LOCs C++ + 2M LOCs Rust). Unfortunately, our team is very small (too small for the task, in fact) and thus we don't have resources to manage the community. Therefore I didn't publish a copy of the crate with improvements anywhere. If someone would be willing to handle further maintenance of the crate, we might publish it.

[futscdav]

I see, that's unfortunate. @dtolnay what's the plan here?

[bruno-j-nicoletti]

Another upvote for this. I want to be able to bridge separate C++ libraries into Rust and place them in different Rust modules, possibly in multiple source files. Code in one bridge needs to use types from another bridge, however this doesn't currently work.

Code below is an example of what I want to do. However it refuses to build complaing that the use of liba_::Image in mod::ui is an 'unsupported type'.

extern crate cxx;

// Bridge to C++ library LibA which we wish to map to rust module lib_a
#[cxx::bridge]
pub mod lib_a {
    #[namespace = "LibA"]
    unsafe extern "C++" {
        // define an image type and simple accessors on it
        pub type Image;
        fn width(self: &Image) -> u32;
        fn height(self: &Image) -> u32;
    }
}

// Bridge to C++ library UI which we wish to map to rust module ui
// The C++ UI library uses types from the C++ LibA library
#[cxx::bridge]
pub mod ui {
    #[namespace = "UI"]
    unsafe extern "C++" {
        // Following line fails to compile, complains "error: unsupported type"
        pub fn getCurrentImage() -> SharedPtr<lib_a::Image>;
    }
}

pub fn print_image_size(img : &lib_a::Image)
{
    print!("Image size is {}x{}\n", img.width(), img.height());
}

pub fn print_current_ui_image_size()
{
    print_image_size(&*ui::getCurrentImage());
}

My Rust skills are currently insufficient to figure out how to fix this, though I see where the check if failing.

[schreter]

@bruno-j-nicoletti

My Rust skills are currently insufficient to figure out how to fix this, though I see where the check if failing.

The feature simply doesn't exist, so it doesn't work that way. That was the reason for this PR in the first place. But, it still sits here unreviewed after a year (together with other PRs and RFCs for design of additional features). In the meantime, we have forked the crate in our company repo, added quite a bit of stuff, and do not try to contribute anymore, sorry.

You might have more luck with https://github.com/google/autocxx or https://github.com/mystor/rust-cpp.