Re: [rust-dev] wrapping a C library (ownership/mutability questions)

2014-01-18 Thread Josh Haberman
On Fri, Jan 17, 2014 at 5:07 PM, Daniel Micay danielmi...@gmail.com wrote: Every type in Rust can be assigned, passed or returned by-value. This is always semantically equivalent to a shallow copy, as they are in C. If the type has a destructor, closure or `mut T` inside then the copy is

[rust-dev] sandboxing Rust?

2014-01-18 Thread Josh Haberman
Is it a design goal of Rust that you will be able to run untrusted code in-process safely? In other words, by whitelisting the set of available APIs and prohibiting unsafe blocks, would you be able to (eventually, once Rust is stable and hardened) run untrusted code in the same address space

Re: [rust-dev] sandboxing Rust?

2014-01-18 Thread Scott Lawrence
On Sat, 18 Jan 2014, Corey Richardson wrote: Rust's safety model is not intended to prevent untrusted code from doing evil things. Doesn't it succesfully do that, though? Or at least with only a small amount of extra logic? For example, suppose I accept, compile, and run arbitrary rust

Re: [rust-dev] sandboxing Rust?

2014-01-18 Thread Corey Richardson
On Sat, Jan 18, 2014 at 10:30 PM, Scott Lawrence byt...@gmail.com wrote: On Sat, 18 Jan 2014, Corey Richardson wrote: Rust's safety model is not intended to prevent untrusted code from doing evil things. Doesn't it succesfully do that, though? It might! But Graydon was very adamant that

[rust-dev] Converting ~[T] embedded in struct to [T]

2014-01-18 Thread Ashish Myles
I understand as per a previous discussion that the owned box ~[T] doesn't quite have the semantics of a unique *pointer*. Below include my successes in some borrowing scenarios and analogous failed attempts at borrowing a reference to a unique pointer to an array within a FooVec struct. How do I

Re: [rust-dev] sandboxing Rust?

2014-01-18 Thread Daniel Micay
On Sat, Jan 18, 2014 at 10:30 PM, Scott Lawrence byt...@gmail.com wrote: On Sat, 18 Jan 2014, Corey Richardson wrote: Rust's safety model is not intended to prevent untrusted code from doing evil things. Doesn't it succesfully do that, though? Or at least with only a small amount of extra

[rust-dev] Cloning a statically-sized array

2014-01-18 Thread Ashish Myles
Now, I already know that statically-sized arrays of primitives are implicitly copyable, but consider, for example, a statically-sized array of a non-copyable but Clone-able type. I find that for v of type [T, ..2], v.clone() is not a static array. Perhaps it's because v is being implicitly

Re: [rust-dev] Cloning a statically-sized array

2014-01-18 Thread Daniel Micay
On Sun, Jan 19, 2014 at 12:17 AM, Ashish Myles marci...@gmail.com wrote: Now, I already know that statically-sized arrays of primitives are implicitly copyable, but consider, for example, a statically-sized array of a non-copyable but Clone-able type. I find that for v of type [T, ..2],

Re: [rust-dev] wrapping a C library (ownership/mutability questions)

2014-01-18 Thread Alex Crichton
Any way to prevent this, so that only I am allowed to create FieldDef structs but can still return references to them in my public API? You'll want something like: pub struct FieldDef { priv field: int, } That way everyone can name your struct, but no one other than you can construct it

Re: [rust-dev] Converting ~[T] embedded in struct to [T]

2014-01-18 Thread Alex Crichton
fn borrow1'a('a self) - 'a int { match (self) { // error: mismatched types: expected `'a int` but found `~int` // (expected -ptr but found ~-ptr) Foo(ref v) = *v } } This doesn't work because the local variable v has type ~int,