New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Native C++ FFI in the same manner as D #602

Open
steveklabnik opened this Issue Jan 21, 2015 · 7 comments

Comments

Projects
None yet
10 participants
@steveklabnik
Member

steveklabnik commented Jan 21, 2015

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

@boghison

This comment has been minimized.

Show comment
Hide comment
@boghison

boghison Mar 29, 2015

Are there any news on this?

boghison commented Mar 29, 2015

Are there any news on this?

@shmerl

This comment has been minimized.

Show comment
Hide comment
@shmerl

shmerl Aug 4, 2015

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

shmerl commented Aug 4, 2015

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

@Leo2807

This comment has been minimized.

Show comment
Hide comment
@Leo2807

Leo2807 Dec 2, 2015

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.

Leo2807 commented Dec 2, 2015

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

This comment has been minimized.

Show comment
Hide comment
@erlend-sh

erlend-sh Dec 2, 2015

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

erlend-sh commented Dec 2, 2015

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

This comment has been minimized.

Show comment
Hide comment
@liuchong

liuchong Apr 18, 2016

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

liuchong commented Apr 18, 2016

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

@burdges

This comment has been minimized.

Show comment
Hide comment
@burdges

burdges Apr 18, 2016

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

burdges commented Apr 18, 2016

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

@ssokolow

This comment has been minimized.

Show comment
Hide comment
@ssokolow

ssokolow Jul 31, 2016

@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".)

ssokolow commented Jul 31, 2016

@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".)

@Centril Centril added the T-lang label Feb 23, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment