Native modules do not support const, enum and type properly.

[beoran]

When playing around with rust 0.1 and trying to wrap Allegro, a game programming library with it I noticed that it's not possible to use enum , or const in a native module . This is annoying since it means I have to use a second non-native module to define the C constants and enums that Allegro uses. Also, type doesn't work well, so again, I have to use another non-native module to define the struct types for Allegro. Could all this be allowed in the future?

Below is an example rewritten for libc:

use std;
import std::io;

mod libc1_nn  {
  enum test { zero, one, two, three }
}


#[nolink]
native mod libc1  {
  enum test { zero, one, two, three } 
}


mod libc2_nn  {
  const constant : int = 10;
}


#[nolink]
native mod libc2  {
  const constant : int = 10;
}


mod libc3_nn {
  type rec = { a : c_int , b : c_int };
}


#[nolink]
native mod libc3  {
  import ctypes::*;
  type rec = { a : c_int , b : c_int };
}

[nikomatsakis]

I don't understand why you have so many modules. You can reference the types from non-native modules in a native module. Does that address your problem?

Also, there is currently an outstanding issue that C-like enums are not represented using a C integer but rather a Rust integer which---on 64-bit platforms---is not the same. That will hopefully be fixed soon.

[beoran]

Those many modules are just there to demonstrate the many aspects of this lacking feature. If you try to compile you'll get compile errors in the native modules, but not in the matching non-native ones.

Yes, I can reference types from the non-native module in the native one, but that means I'll need to use 2 modules, one native and another non-native wrapper module. It would be far handier if that wasn't needed, and if const, enum and type would work also in native modules.

The enum problem you mention is also a bit of a bummer, but that's not what I was getting at. Anyway, thanks for listening to me!

[marijnh]

To clarify, this is just what native modules are -- they are only there to define foreign functions, nothing else. By design.

We're working on improving export to support easier re-exporting of other modules' contents. That'll make it easier to fold a set of bindings into your module if you want.

[graydon]

Recording as enhancement request. I'd take a pull req implementing it but it seems pretty low priority since it's easy to work around.

[brson]

I would prefer to just get rid of native modules completely, add a 'native' qualifier to functions, and use use attributes to set up the native context.

[catamorphism]

Closing this as per @brson 's last comment.