Native C++ FFI in the same manner as D

[steveklabnik]

Issue by bstrie
Friday Apr 12, 2013 at 14:04 GMT

For earlier discussion, see rust-lang/rust#5853

This issue was labelled with: A-an-interesting-project, A-ffi, E-hard, I-wishlist, P-low in the Rust repository

---

@sanxiyn and @jdm have expressed interest in doing this, possibly in the 0.8 cycle.

http://www.reddit.com/r/rust/comments/1c3clf/c_ffi/c9codm1

[cuzbog]

Are there any news on this?

[shmerl]

I'd be interested in using Rust with Qt which will probably require this.

[Leo2807]

Wouldn't it be better if we made a class ffi syntax, allowing other object-oriented language ffi packages (like grust) to interface with it? This should prevent multiple class syntaxes from arising making ffi not needlessly complex, wile at the same time easing the implementation of ffi packages.

[erlend-sh]

There's a more up to date discussion on C++ interop over on Rust Internals:

https://internals.rust-lang.org/t/better-c-interoperability/2650?u=erlend_sh

[liuchong]

Hi, what's the current status on this? 🌚

[burdges]

Just fyi @shmerl there is an effort to make QtQuick bindings : https://github.com/cyndis/qmlrs

[ssokolow]

@burdges I don't know whether @shmerl has similar concerns but, for me, QtQuick is completely unsuitable because its support for native widgets is immature and, by its very nature, it runs counter to my "maximal compile-time verification" goal since QML would be code I'd have to get right, which Rust can't check at compile time.

(Most of my projects are firmly I/O-bound and my whole reason for wanting to replace Python with Rust is that, to approximately quote the title of a YouTube video I saw in the sidebar, "a type is worth a thousand tests".)