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
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
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
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
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
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
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
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],
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
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,
10 matches
Mail list logo