Patrick Walton pcwal...@mozilla.com wrote:
On 7/21/14 2:22 PM, Tobias Müller wrote:
We discussed this with Bartosz literally for weeks (him being a fan of
auto_ptr for too long, later completely converted against it and I take
credit for that :o)). With auto_ptr this was possible:
On Mon, Jul 21, 2014 at 2:45 PM, Patrick Walton pcwal...@mozilla.com
wrote:
... in C++. Not in Rust. That's because, unlike C++, Rust is designed
from the ground up to support moves and copies in a first class way.
As a C++ dev, I feel the need to say THANK YOU for that. Rust being
designed
On 23/07/14 07:10, Tobias Müller wrote:
... in C++. Not in Rust. That's because, unlike C++, Rust is designed
from the ground up to support moves and copies in a first class way.
It's just strange that you can change the semantic of an already existing
operation just by adding new
On 2014-07-21 06:06, Patrick Walton wrote:
On 7/20/14 9:04 PM, Patrick Walton wrote:
On 7/20/14 8:12 PM, David Henningsson wrote:
Cool, thanks for the answer. These restrictions seem somewhat complex.
They are required. Otherwise we would end up with a C++-like situation
where copies end
On 7/21/14 8:49 AM, Tobias Müller wrote:
Patrick Walton pcwal...@mozilla.com wrote:
On 7/20/14 8:12 PM, David Henningsson wrote:
From a language design perspective, maybe it would be more intuitive to
have different syntaxes for copy and move, like:
As a rust newbie, that aspect aways
Patrick Walton pcwal...@mozilla.com wrote:
On 7/21/14 8:49 AM, Tobias Müller wrote:
As a rust newbie, that aspect aways makes me a bit nervous. Two quite
different operations with the same syntax and and simply changing a detail
in the struct can be enough to switch between the two.
This is
On 7/21/14 2:22 PM, Tobias Müller wrote:
We discussed this with Bartosz literally for weeks (him being a fan of
auto_ptr for too long, later completely converted against it and I take
credit for that :o)). With auto_ptr this was possible:
auto_ptrint a(new int);
auto_ptrint b = a;
It would
That's right. `BufferedReader` takes the `Reader` it wraps by-value,
but the `read` method takes `mut self`. Moving something doesn't
require it to be stored in a mutable variable, but taking a `mut` to
it does.
On Sun, Jul 20, 2014 at 6:29 PM, David Henningsson di...@ubuntu.com wrote:
Hi,
On 7/20/14 6:29 PM, David Henningsson wrote:
Hi,
Consider these two examples:
1)
let mut file = File::open(filename);
file.read(buf);
2)
let file = File::open(filename);
let mut reader = BufferedReader::new(file);
reader.read(buf);
My question is: in example 2, why doesn't BufferedReader
On 2014-07-21 03:33, Patrick Walton wrote:
On 7/20/14 6:29 PM, David Henningsson wrote:
Hi,
Consider these two examples:
1)
let mut file = File::open(filename);
file.read(buf);
2)
let file = File::open(filename);
let mut reader = BufferedReader::new(file);
reader.read(buf);
My question
Because Foo is a POD type (implements the Copy trait). Essentially, types that
can be copied by copying bits only (not allocating) are POD types, and all
others move.
This may be changed with the Opt-In Built-in Traits proposal so that POD types
must be specially declared to implement Copy
Some types are implicitly copyable. They implement the built-in trait Copy.
A type is Copy if it is
a) numeric primitive (e.g. f32 or uint), or
b) an immutable reference (e.g. Foo or str), or
c) a raw pointer (e.g. *const Foo or *mut Foo), or
d) a collection of Copy types (e.g. struct Foo { a:
On 2014-07-21 04:43, Steven Fackler wrote:
Some types are implicitly copyable. They implement the built-in trait
Copy. A type is Copy if it is
a) numeric primitive (e.g. f32 or uint), or
b) an immutable reference (e.g. Foo or str), or
c) a raw pointer (e.g. *const Foo or *mut Foo), or
d) a
On 7/20/14 8:12 PM, David Henningsson wrote:
Cool, thanks for the answer. These restrictions seem somewhat complex.
They are required. Otherwise we would end up with a C++-like situation
where copies end up happening too frequently.
This wasn't very intuitive for me, so just throwing this
On 7/20/14 9:04 PM, Patrick Walton wrote:
On 7/20/14 8:12 PM, David Henningsson wrote:
Cool, thanks for the answer. These restrictions seem somewhat complex.
They are required. Otherwise we would end up with a C++-like situation
where copies end up happening too frequently.
Also note that
15 matches
Mail list logo
