Split Module Definitions

[DylanLukes]

Within the same file and module, modules should be able to be split up and combined at compile-time. This would allow putting non-native functions in a native module, in turn allowing convenient use of opaque forms. For example:

mod objc {
  // Opaque type for objc objects. This might more realistically be a resource type to handle ObjC reference counting.
  tag id { _id(unsafe::id) }

  // safe version
  fn get_class(name: str) -> id {
    _id(str::as_buf(name, {|name_buf| unsafe::objc_getClass(name_buf)}))
  } 

  mod unsafe {
    // non-opaque type for objc objects
    type void  = int;
    type cls = *void;
    type id = *{isa: cls};
  }
  native mod unsafe {
    fn objc_getClass(name: str::sbuf) -> id;
  }
}

[brson]

We could also just allow native function declarations in regular modules. We could even eliminate native mods altogether and just give regular mods some attributes to use by default for native functions, like:

#[native(name = "libc")]
#[native(abi = "stdcall")]
mod {
    native fn printf(...);
}

[jsternberg]

Just chiming in, I like the idea of having native act on a specific function instead of on a module. I don't like the syntax presented in the brson's comment though. Instead of a native macro acting on a module, maybe the native macro should be a crate definition similar to the link macro?

For example, for linking to something like sqlite3.

// sqlite3.rc
// probably name this something different, only specifies what to link against
// (instead of searching for a rust library, searches for a normal shared lib)
#[native(name="sqlite3")];
#[link(name="sqlite3", vers="3.0", ...)];

mod sqlite3;

// sqlite3.rs
mod unsafe {
    // specify the abi
    #[native(abi="stdcall")] fn printf(...);
    // default to stdcall
    #[native] fn fprintf(...);
}

// would also work for tagging an entire module as native
#[native]
mod nativestuff {
    fn foobar();
}

That way, link definitions are kept in the crate file (which is already used to determine compilation anyway) and the information doesn't have to be repeated for every native module. The native macro would essentially be the equivalent of extern "C". It's also easily extended to working on modules.

[graydon]

I think between export globbing and the reforms planned on extern, this can safely be put to rest. We'll be able to declare extern functions one-by-one, and permitting multiple fragments of a module seems like .. a plausible way to address this space, but probably a redundant one, given all the other options. Closing.