Well, I did. It all works very well until I pulled down the latest source.
I'd like to dive into the rust source code but where to start?
On Sat, Jan 18, 2014 at 3:48 PM, Daniel Micay wrote:
> On Sat, Jan 18, 2014 at 2:45 AM, Edward Wang
> wrote:
> > Hi list,
> >
> > I built a rustc minutes ag
On Sat, Jan 18, 2014 at 2:45 AM, Edward Wang wrote:
> Hi list,
>
> I built a rustc minutes ago from the source to pull down Niko's fix for
> temporary lifetime (https://github.com/mozilla/rust/pull/11585). It works
> great. In the meantime, there seems to be a possible regression introduced
> by u
Hi list,
I built a rustc minutes ago from the source to pull down Niko's fix for
temporary lifetime (https://github.com/mozilla/rust/pull/11585). It works
great. In the meantime, there seems to be a possible regression introduced
by unknown commit of the past day or so. That is, the eh-personality
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 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
>> 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 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
> 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
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
> 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.
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,
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
Hello,
I’m delighted that this topic is on the mailing list again, last time it wasn’t
very popular, and I think rustc is more ready for this now than last time when
I tried to implement it. Especially syntax extensions and feature flags.
I wrote a bit of thoughts after my last attempt on my bl
13 matches
Mail list logo
