I wrote up an alternative proposal that I think, if I’m understanding them
correctly, meets all the requirements. I submitted it as an RFC, so discussion
of it is probably better put on github on the mailing list, but in case anyone
interested is watching this thread and not watching the RFCs:
This will work for your pattern match without cloning:
match self.opt_err {
None => format!("compilation failed at offset {:u}", self.erroffset
as uint),
Some(ref s) => format!("compilation failed at offset {:u}: {:s}",
self.erroffset as uint, *s)
}
I
This should work:
let obj = (self.produce_obj)();
Original Message
From: Oren Ben-Kiki
Sent: Fri Nov 08 18:33:23 EST 2013
To: wuyunlong
Cc: "rust-dev@mozilla.org"
Subject: Re: [rust-dev] Help: How to execute the owned method "produce_obj"?
It wouldn't be self.something beca
It's looking for a Reader impl for @TcpStream, which does not exist. The
implementation is for TcpStream (no @). BufferedReader needs to own its
underlying stream, and therefore takes it by value, not as a shared box. If
you take out the @ when you declare the stream variable it'll compile (w
Hi rust folks,
I've been tinkering with a rust binding for creating filesystems in userspace
(FUSE) for a while now. It's not at all done, but has now reached the point
where I think it's worth showing around for feedback if anyone's interested.
Even if you're not interested in FUSE itself, t
Speaking of macros and overly nested functional style--I had some code with
deeply nested "do" blocks and experimented with a multi_do macro that creates
syntax reminiscent of haskell's "do" notation. It's more syntactically noisy
than would be preferable--I couldn't get it to parse unambiguous
> I'd settle for the ability to say: update_in_place(foo.owned_pointer, &fn(~T)
> -> ~T) - surely this would be safe?
That would interact with Drop in a way that could cause a memory violation
after a task failure. The problem is that if you allow a moved value to be
destroyed before something
> The only way to implement .finished() non destructively (so that, when
> returning false, it does not eat an element) is with a Peekable iterator as
> in this pull request:
>
> https://github.com/mozilla/rust/pull/8428
>
> Then .finished() is .peek().is_none().
If you loop all the way throug
> So in general, using std I/O from outside of tasks is going to continue to be
> sketchy for quite a while.
Thanks for the info, unfortunate though it may be. Given this, it doesn't look
like I should bother even trying to get anything to work with the high level
FUSE API providing its own th
Hi Rust devs,
What can I assume about the safety of having a C library spawn its own threads,
from which it calls function pointers to "extern" functions written in rust?
My guess (and only a guess--I have no actual reasoning behind it) would be
something like this:
* I cannot expect anythi
10 matches
Mail list logo
