Hi Rust experts,
I would love your advice on how to wrap my C library with Rust, and
particularly how to map my library's ownership/mutability semantics
onto idiomatic Rust types, since my library's ownership/mutability
model is a great match for Rust's approach.
My library's objects have a two-p
I can help with the first question. You can use move semantics to do this.
For example:
```
pub struct MessageDef {
fullname: ~str,
}
impl MessageDef {
fn new() -> MessageDef { MessageDef { ... } }
fn set_fullname(&mut self, s: &str) { self.fullname = s.to_str(); }
}
pub struct Messa
> Hi Rust experts,
How flattering!
> This seems like a great match for Rust, because an object could be
> created as "mut" and local to a single task, but then "become" non-mut
> and be sharable between tasks once frozen. And the refcounting scheme
> sounds like a great match for the Arc model.
Hi there, thanks for the friendly replies. This is really helpful.
> You may want to think about things a little differently
> though. Using something like Arc means that the refcounting
> is managed in rust, whereas it sounds like you're already
> dealing with it in your library.
Yes, I didn't m
> This is the part that I don't follow; why can't I just mark
> my mutable-only methods as taking a mutable self?
The problem with this is that it requires that the *owner* of a type
have a *mutable slot*, and you cannot prevent owners from declaring
their slots as mutable. In the example you gave
On Fri, Jan 17, 2014 at 4:32 PM, Alex Crichton wrote:
>> This is the part that I don't follow; why can't I just mark
>> my mutable-only methods as taking a mutable self?
>
> The problem with this is that it requires that the *owner* of a type
> have a *mutable slot*, and you cannot prevent owners
>> The problem with this is that it requires that the *owner* of a type
>> have a *mutable slot*, and you cannot prevent owners from declaring
>> their slots as mutable. In the example you gave, you could write "let
>> mut var2 = Box { x: 2 }" and it would compile, there's nothing
>> preventing usa
On Fri, Jan 17, 2014 at 7:53 PM, Josh Haberman wrote:
>
> Are you saying (if I may lapse into C++ vocab for a moment) that I can't
> hide the copy constructor? Anyone can copy my non-mut struct into a
> mut struct at any time and I don't have any say in the matter?
>
> Feel free to correct this in
On Fri, Jan 17, 2014 at 8:07 PM, Daniel Micay wrote:
> On Fri, Jan 17, 2014 at 7:53 PM, Josh Haberman wrote:
>>
>> Are you saying (if I may lapse into C++ vocab for a moment) that I can't
>> hide the copy constructor? Anyone can copy my non-mut struct into a
>> mut struct at any time and I don't
On Fri, Jan 17, 2014 at 5:07 PM, Daniel Micay 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 considered a move of o
> 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
11 matches
Mail list logo
