On 9/30/11 9:55 AM, Marijn Haverbeke wrote:
Not anymore, with the C decl.
Can you elaborate on that?
Native functions with the C stack ABI are what we've been calling "bare
functions". That is, |bind| doesn't work with them, and they take no
environment. So no wrapper function is needed.
The reason is that I felt that having two layers of indirection per C
function call (one for the wrapper, and one for the stack switching
stub, both of which actually set up new stack frames) was excessive.
Also, in the vast majority of cases, the programmer doesn't need to bind
to a native function, so using wrappers tends to generate a lot of code
in the crate that doesn't actually buy us anything.
I probably should have cleared this first with the mailing list, sorry.
How about what I proposed earlier: the '+' sigil means by-value, the '&'
sigil means by-immutable-reference, and leaving it off has the compiler
choose a sensible default based on the type?
That'd work, though it'd be a little obscure (a function fn<T>(T) will
always take its arg by reference, even when instantiated with T=int).
I guess it's a good stopgap until we decide what to do with
monomorphizing.
Well, with type passing that's what we end up having to do.
Would passing structural types by value be allowed?
Doesn't matter much to me. I guess it allows the copy operator to become
a function, if we want to do that (Brian floated this idea). Not high
priority though, I don't think.
How would that look? (Using load/store as we used to do, or passing by pointer
with
the caller owning the value, or passed by pointer with the callee
copying it into its frame?)
My preference is for whatever clang does :) Looks like it passes by
pointer with the LLVM |byval| attribute. This causes LLVM to
automatically copy on the callee side AFAICT.
Patrick
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
