Re: [rust-dev] Auto-borrow/deref (again, sorry)
We have to say `mut i` in main() because `i` is non-mutable. We’re explicitly
taking a mutable borrow.
But once it’s in foo(), it’s already mutable. The type `mut int` carries its
mutability with it. Having to say `mut` again makes no sense and is nothing but
pure noise.
-Kevin
On Dec 27, 2013, at 4:59 PM, Vadim vadi...@gmail.com wrote:
For the same reason we currently have to say `mut i` in main() - to
explicitly acknowledge that the callee may mutate i. By the same logic, this
should be done everywhere.
On Wed, Dec 25, 2013 at 3:11 PM, Kevin Ballard ke...@sb.org wrote:
On Dec 25, 2013, at 5:17 PM, Vadim vadi...@gmail.com wrote:
I agree that unexpected mutation is undesirable, but:
- requiring 'mut' is orthogonal to requiring '' sigil, IMHO,
- as currently implemented, Rust does not always require mut when callee
mutates the argument, for example:
fn main() {
let mut i: int = 0;
foo(mut i);
println!({}, i);
}
fn foo(i: mut int) {
bar(i); // no mut!
}
fn bar(i: mut int) {
*i = *i + 1;
}
Note that invocation of bar() inside foo() does not forewarn reader by
requiring 'mut'. Wouldn't you rather see this?:
fn main() {
let mut i: int = 0;
foo(mut i);
println!({}, i);
}
fn foo(i: mut int) {
bar(mut i);
}
fn bar(i: mut int) {
i = i + 1;
}
What is the point of adding `mut` here? bar() does not need `mut` because
calling bar(i) does not auto-borrow i. It’s already a `mut int`.
-Kevin
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] Using libgreen/libnative
Greetings rusticians!
Recently pull request #10965 landed, so the rust standard library no longer has
any scheduling baked into it, but rather it's refactored out into two libraries.
This means that if you want a 1:1 program, you can jettison all M:N support with
just a few `extern mod` statements. A brief overview of the current state of
things is:
1. All programs not using std::rt directly should still continue to operate as
usual today
2. All programs still start up in M:N mode, although this will likely change
once 1:1 I/O work has been completed
3. There are two more libraries available, libgreen and libnative, which allow
custom fine-grained control over how programs run.
4. Whenever a new task is spawned, it is by default spawned as a sibling which
means that it is spawned in the same mode as the spawning thread. This means
that if a green thread spawns a thread then it will also be a green thread,
while a native thread will spawn another OS thread.
With this migration, there have been a few changes in the public APIs, and
things still aren't quite where I'd like them to be. PR #11153 is the last major
step in this process as it allows you to link to both libnative and libgreen,
yet still choose which one is used to boot your program. Some breaking changes
you may notice are:
* it's still not possible to easily start up in 1:1 mode - This is fixed by
#11153. In the meantime, you can use #[start] with native::start in order to
boot up in 1:1 mode. Be warned though that the majority of I/O is still
missing from libnative (see PR #11159 for some progress)
https://gist.github.com/8162357
* std::rt::{start, run} are gone - These are temporarily moved into green/native
while #[boot] is getting sorted out. The green/native counterparts perform as
you would expect.
https://gist.github.com/8162372
* std::rt::start_on_main_thread is gone - This function has been removed with no
direct counterpart. As a consequence of refactoring the green/native
libraries, the single threaded spawn mode for a task has been removed (this
doesn't make sense in 1:1 land). This behavior can be restored by directly
using libnative and libgreen. You can use libgreen to spin up a pool of
schedulers and then use libnative for the main task to do things like GUI
management.
https://gist.github.com/8162399
And of course with the removal of some features comes the addition of new ones!
Some new things you may notice are:
* libstd is no longer burdened with libgreen and libnative! This means that the
compile times for libstd should be a little faster, but most notably those
applications only using libstd will have even less code pulled in than before,
meaning that libstd is that much closer to being used in a bare metal
context. It's still aways off, but we're getting closer every day!
* libgreen has a full-fleged SchedPool type. You can see a bit of how it's used
in gist I posted above. This type is meant to represent a dynamic pool of
schedulers. Right now it's not possible to remove a scheduler from the pool
(requires some more thought and possibly libuv modifications), but you can add
new schedulers dynamically to the pool.
This type supercedes the ThreadPool type in libextra at this point, and
management of a SchedPool should provide any fine-grained control needed over
the 'M' number in an M:N runtime.
* libgreen and libnative can be used directly to guarantee spawning a green or a
native task, regardless of the flavor of task that is doing the spawning.
In the coming months, I plan on filling out more native I/O to bring it up to
speed with the M:N implementation. I also plan on rewriting the core components
of extra::comm to be performant in both scheduling modes in order to bring the
extra::{comm, arc, sync} primitives up to date with their std::comm
counterparts.
If there are any questions about any of this, feel free to ask me! This thread
is always available, and I'm also reachable as acrichto on IRC or alexcrichton
on github.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Auto-borrow/deref (again, sorry)
I think I see the confusion (as I suffered from the same point of
confusion). So let me restate your answer and please correct me of I am
wrong.
1. mut int and mut int are different types and the former doesn't
automatically convert to the latter.
2. The way to get the latter from the former is to say mut i since i
is defined as taking a non-mut borrow even if i is mut. (This was the point
of confusion I believe.)
3. No explicit conversion is needed within foo() since the type of i is
already mut int.
Ashish
On Dec 28, 2013 1:33 PM, Kevin Ballard ke...@sb.org wrote:
We have to say `mut i` in main() because `i` is non-mutable. We’re
explicitly taking a mutable borrow.
But once it’s in foo(), it’s *already* mutable. The type `mut int`
carries its mutability with it. Having to say `mut` again makes no sense
and is nothing but pure noise.
-Kevin
On Dec 27, 2013, at 4:59 PM, Vadim vadi...@gmail.com wrote:
For the same reason we currently have to say `mut i` in main() - to
explicitly acknowledge that the callee may mutate i. By the same logic,
this should be done everywhere.
On Wed, Dec 25, 2013 at 3:11 PM, Kevin Ballard ke...@sb.org wrote:
On Dec 25, 2013, at 5:17 PM, Vadim vadi...@gmail.com wrote:
I agree that unexpected mutation is undesirable, but:
- requiring 'mut' is orthogonal to requiring '' sigil, IMHO,
- as currently implemented, Rust does not always require mut when callee
mutates the argument, for example:
fn main() {
let mut i: int = 0;
foo(mut i);
println!({}, i);
}
fn foo(i: mut int) {
bar(i); // no mut!
}
fn bar(i: mut int) {
*i = *i + 1;
}
Note that invocation of bar() inside foo() does not forewarn reader by
requiring 'mut'. Wouldn't you rather see this?:
fn main() {
let mut i: int = 0;
foo(mut i);
println!({}, i);
}
fn foo(i: mut int) {
bar(mut i);
}
fn bar(i: mut int) {
i = i + 1;
}
What is the point of adding `mut` here? bar() does not need `mut` because
calling bar(i) does not auto-borrow i. It’s *already* a `mut int`.
-Kevin
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Auto-borrow/deref (again, sorry)
On Dec 28, 2013, at 1:53 PM, Ashish Myles marci...@gmail.com wrote:
I think I see the confusion (as I suffered from the same point of confusion).
So let me restate your answer and please correct me of I am wrong.
1. mut int and mut int are different types and the former doesn't
automatically convert to the latter.
Effectively correct. `mut int` isn’t actually a type, `int` is a type and the
`mut` here means that the slot is mutable. `mut int` is a type. You can in
fact have `mut i: mut int` to have a mutable slot containing a `mut int`.
This would allow you to replace the pointer stored in `i` with a different
pointer. If the slot is not mutable, the pointer is fixed but because it’s a
`mut int` the data that’s being pointed to can be modified.
2. The way to get the latter from the former is to say mut i since i is
defined as taking a non-mut borrow even if i is mut. (This was the point of
confusion I believe.)
Correct.
There is in fact one way to automatically borrow `mut i` to `mut i`, and
that’s when calling a method on `i` that takes `mut self`. But I believe
that’s the only way to automatically perform this borrowing.
3. No explicit conversion is needed within foo() since the type of i is
already mut int”.
Correct.
-Kevin
Ashish
On Dec 28, 2013 1:33 PM, Kevin Ballard ke...@sb.org wrote:
We have to say `mut i` in main() because `i` is non-mutable. We’re
explicitly taking a mutable borrow.
But once it’s in foo(), it’s already mutable. The type `mut int` carries its
mutability with it. Having to say `mut` again makes no sense and is nothing
but pure noise.
-Kevin
On Dec 27, 2013, at 4:59 PM, Vadim vadi...@gmail.com wrote:
For the same reason we currently have to say `mut i` in main() - to
explicitly acknowledge that the callee may mutate i. By the same logic,
this should be done everywhere.
On Wed, Dec 25, 2013 at 3:11 PM, Kevin Ballard ke...@sb.org wrote:
On Dec 25, 2013, at 5:17 PM, Vadim vadi...@gmail.com wrote:
I agree that unexpected mutation is undesirable, but:
- requiring 'mut' is orthogonal to requiring '' sigil, IMHO,
- as currently implemented, Rust does not always require mut when callee
mutates the argument, for example:
fn main() {
let mut i: int = 0;
foo(mut i);
println!({}, i);
}
fn foo(i: mut int) {
bar(i); // no mut!
}
fn bar(i: mut int) {
*i = *i + 1;
}
Note that invocation of bar() inside foo() does not forewarn reader by
requiring 'mut'. Wouldn't you rather see this?:
fn main() {
let mut i: int = 0;
foo(mut i);
println!({}, i);
}
fn foo(i: mut int) {
bar(mut i);
}
fn bar(i: mut int) {
i = i + 1;
}
What is the point of adding `mut` here? bar() does not need `mut` because
calling bar(i) does not auto-borrow i. It’s already a `mut int`.
-Kevin
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Using libgreen/libnative
This is awesome!
I have a question: does the #[boot] addition mean that we now have 5
ways to (partially) set-up the entry point of a program?
- fn main
- #[main]
- #[start]
- #[boot]
- #[lang=start]
Huon
On 29/12/13 05:37, Alex Crichton wrote:
Greetings rusticians!
Recently pull request #10965 landed, so the rust standard library no longer has
any scheduling baked into it, but rather it's refactored out into two libraries.
This means that if you want a 1:1 program, you can jettison all M:N support with
just a few `extern mod` statements. A brief overview of the current state of
things is:
1. All programs not using std::rt directly should still continue to operate as
usual today
2. All programs still start up in M:N mode, although this will likely change
once 1:1 I/O work has been completed
3. There are two more libraries available, libgreen and libnative, which allow
custom fine-grained control over how programs run.
4. Whenever a new task is spawned, it is by default spawned as a sibling which
means that it is spawned in the same mode as the spawning thread. This means
that if a green thread spawns a thread then it will also be a green thread,
while a native thread will spawn another OS thread.
With this migration, there have been a few changes in the public APIs, and
things still aren't quite where I'd like them to be. PR #11153 is the last major
step in this process as it allows you to link to both libnative and libgreen,
yet still choose which one is used to boot your program. Some breaking changes
you may notice are:
* it's still not possible to easily start up in 1:1 mode - This is fixed by
#11153. In the meantime, you can use #[start] with native::start in order to
boot up in 1:1 mode. Be warned though that the majority of I/O is still
missing from libnative (see PR #11159 for some progress)
https://gist.github.com/8162357
* std::rt::{start, run} are gone - These are temporarily moved into green/native
while #[boot] is getting sorted out. The green/native counterparts perform as
you would expect.
https://gist.github.com/8162372
* std::rt::start_on_main_thread is gone - This function has been removed with no
direct counterpart. As a consequence of refactoring the green/native
libraries, the single threaded spawn mode for a task has been removed (this
doesn't make sense in 1:1 land). This behavior can be restored by directly
using libnative and libgreen. You can use libgreen to spin up a pool of
schedulers and then use libnative for the main task to do things like GUI
management.
https://gist.github.com/8162399
And of course with the removal of some features comes the addition of new ones!
Some new things you may notice are:
* libstd is no longer burdened with libgreen and libnative! This means that the
compile times for libstd should be a little faster, but most notably those
applications only using libstd will have even less code pulled in than
before,
meaning that libstd is that much closer to being used in a bare metal
context. It's still aways off, but we're getting closer every day!
* libgreen has a full-fleged SchedPool type. You can see a bit of how it's used
in gist I posted above. This type is meant to represent a dynamic pool of
schedulers. Right now it's not possible to remove a scheduler from the pool
(requires some more thought and possibly libuv modifications), but you can
add
new schedulers dynamically to the pool.
This type supercedes the ThreadPool type in libextra at this point, and
management of a SchedPool should provide any fine-grained control needed over
the 'M' number in an M:N runtime.
* libgreen and libnative can be used directly to guarantee spawning a green or a
native task, regardless of the flavor of task that is doing the spawning.
In the coming months, I plan on filling out more native I/O to bring it up to
speed with the M:N implementation. I also plan on rewriting the core components
of extra::comm to be performant in both scheduling modes in order to bring the
extra::{comm, arc, sync} primitives up to date with their std::comm
counterparts.
If there are any questions about any of this, feel free to ask me! This thread
is always available, and I'm also reachable as acrichto on IRC or alexcrichton
on github.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Auto-borrow/deref (again, sorry)
Right, that's how it works now. But I was speculating on how it could
work with auto-borrow. Specifically, I was addressing comex's concern that
C++-like reference auto-borrowing would make it non-obvious when the callee
might mutate the value.
You could have said Well, I've already declared my variable as mutable,
i.e. `let mut i = 0`. Since is already mutable, why do I have to say mut
again when borrowing? The compiler could have easily inferred that. I
believe the answer is To help readers of this code realize that the called
function is [most likely] going to mutate the variable. I believe the
same logic should apply to mut references.
I know that when I write my code, *on the caller side*, I am much more
concerned about which calls are going to mutate my variables, then about
whether they are passed by-value or by-reference. After all, the callee
has already chosen that for me.
And, judging by the number of C++ projects that ban non-const references
but nave no problem with const ones, I think that a significant proportion
of developers feel similarly.
Vadim
On Sat, Dec 28, 2013 at 10:03 AM, Kevin Ballard ke...@sb.org wrote:
We have to say `mut i` in main() because `i` is non-mutable. We’re
explicitly taking a mutable borrow.
But once it’s in foo(), it’s *already* mutable. The type `mut int`
carries its mutability with it. Having to say `mut` again makes no sense
and is nothing but pure noise.
-Kevin
On Dec 27, 2013, at 4:59 PM, Vadim vadi...@gmail.com wrote:
For the same reason we currently have to say `mut i` in main() - to
explicitly acknowledge that the callee may mutate i. By the same logic,
this should be done everywhere.
On Wed, Dec 25, 2013 at 3:11 PM, Kevin Ballard ke...@sb.org wrote:
On Dec 25, 2013, at 5:17 PM, Vadim vadi...@gmail.com wrote:
I agree that unexpected mutation is undesirable, but:
- requiring 'mut' is orthogonal to requiring '' sigil, IMHO,
- as currently implemented, Rust does not always require mut when callee
mutates the argument, for example:
fn main() {
let mut i: int = 0;
foo(mut i);
println!({}, i);
}
fn foo(i: mut int) {
bar(i); // no mut!
}
fn bar(i: mut int) {
*i = *i + 1;
}
Note that invocation of bar() inside foo() does not forewarn reader by
requiring 'mut'. Wouldn't you rather see this?:
fn main() {
let mut i: int = 0;
foo(mut i);
println!({}, i);
}
fn foo(i: mut int) {
bar(mut i);
}
fn bar(i: mut int) {
i = i + 1;
}
What is the point of adding `mut` here? bar() does not need `mut` because
calling bar(i) does not auto-borrow i. It’s *already* a `mut int`.
-Kevin
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Using libgreen/libnative
On 12/28/2013 04:12 PM, Huon Wilson wrote:
This is awesome!
I have a question: does the #[boot] addition mean that we now have 5
ways to (partially) set-up the entry point of a program?
- fn main
- #[main]
- #[start]
- #[boot]
- #[lang=start]
Yeah, pretty much, and there's also a 6th way of defining an entry point
- by using #[no_main] and just defining main like in C. Alex and I had a
pretty decent laugh when we decided to add #[boot] to the mix. Note
though that #[boot] won't define a new entry point - it just changes how
the runtime configures itself before running main. Clearly, this is
getting pretty silly and this will continue to evolve, and hopefully
we'll end up in a spot where most users don't need to know about all
these mechanisms.
Huon
On 29/12/13 05:37, Alex Crichton wrote:
Greetings rusticians!
Recently pull request #10965 landed, so the rust standard library no
longer has
any scheduling baked into it, but rather it's refactored out into two
libraries.
This means that if you want a 1:1 program, you can jettison all M:N
support with
just a few `extern mod` statements. A brief overview of the current
state of
things is:
1. All programs not using std::rt directly should still continue to
operate as
usual today
2. All programs still start up in M:N mode, although this will likely
change
once 1:1 I/O work has been completed
3. There are two more libraries available, libgreen and libnative,
which allow
custom fine-grained control over how programs run.
4. Whenever a new task is spawned, it is by default spawned as a
sibling which
means that it is spawned in the same mode as the spawning thread.
This means
that if a green thread spawns a thread then it will also be a
green thread,
while a native thread will spawn another OS thread.
With this migration, there have been a few changes in the public
APIs, and
things still aren't quite where I'd like them to be. PR #11153 is the
last major
step in this process as it allows you to link to both libnative and
libgreen,
yet still choose which one is used to boot your program. Some
breaking changes
you may notice are:
* it's still not possible to easily start up in 1:1 mode - This is
fixed by
#11153. In the meantime, you can use #[start] with native::start
in order to
boot up in 1:1 mode. Be warned though that the majority of I/O is
still
missing from libnative (see PR #11159 for some progress)
https://gist.github.com/8162357
* std::rt::{start, run} are gone - These are temporarily moved into
green/native
while #[boot] is getting sorted out. The green/native counterparts
perform as
you would expect.
https://gist.github.com/8162372
* std::rt::start_on_main_thread is gone - This function has been
removed with no
direct counterpart. As a consequence of refactoring the green/native
libraries, the single threaded spawn mode for a task has been
removed (this
doesn't make sense in 1:1 land). This behavior can be restored by
directly
using libnative and libgreen. You can use libgreen to spin up a
pool of
schedulers and then use libnative for the main task to do things
like GUI
management.
https://gist.github.com/8162399
And of course with the removal of some features comes the addition of
new ones!
Some new things you may notice are:
* libstd is no longer burdened with libgreen and libnative! This
means that the
compile times for libstd should be a little faster, but most
notably those
applications only using libstd will have even less code pulled in
than before,
meaning that libstd is that much closer to being used in a bare
metal
context. It's still aways off, but we're getting closer every day!
* libgreen has a full-fleged SchedPool type. You can see a bit of how
it's used
in gist I posted above. This type is meant to represent a dynamic
pool of
schedulers. Right now it's not possible to remove a scheduler from
the pool
(requires some more thought and possibly libuv modifications), but
you can add
new schedulers dynamically to the pool.
This type supercedes the ThreadPool type in libextra at this
point, and
management of a SchedPool should provide any fine-grained control
needed over
the 'M' number in an M:N runtime.
* libgreen and libnative can be used directly to guarantee spawning a
green or a
native task, regardless of the flavor of task that is doing the
spawning.
In the coming months, I plan on filling out more native I/O to bring
it up to
speed with the M:N implementation. I also plan on rewriting the core
components
of extra::comm to be performant in both scheduling modes in order to
bring the
extra::{comm, arc, sync} primitives up to date with their std::comm
counterparts.
If there are any questions about any of this, feel free to ask me!
This thread
is always available, and I'm also reachable as acrichto on IRC or
alexcrichton
on github.
Re: [rust-dev] Using libgreen/libnative
Thanks for writing this up, Alex. The improvements you've made to the
runtime recently are very impressive. Now we've got nearly complete and
reasonably fast I/O, fast message passing, a scheduler-agnostic standard
library, and very soon an embeddable runtime and a standard library that
can be used in almost any environment. After years of iteration I'm
hopeful that we're finally converging on a good design for the runtime.
On 12/28/2013 10:37 AM, Alex Crichton wrote:
Greetings rusticians!
Recently pull request #10965 landed, so the rust standard library no longer has
any scheduling baked into it, but rather it's refactored out into two libraries.
This means that if you want a 1:1 program, you can jettison all M:N support with
just a few `extern mod` statements. A brief overview of the current state of
things is:
1. All programs not using std::rt directly should still continue to operate as
usual today
2. All programs still start up in M:N mode, although this will likely change
once 1:1 I/O work has been completed
3. There are two more libraries available, libgreen and libnative, which allow
custom fine-grained control over how programs run.
4. Whenever a new task is spawned, it is by default spawned as a sibling which
means that it is spawned in the same mode as the spawning thread. This means
that if a green thread spawns a thread then it will also be a green thread,
while a native thread will spawn another OS thread.
With this migration, there have been a few changes in the public APIs, and
things still aren't quite where I'd like them to be. PR #11153 is the last major
step in this process as it allows you to link to both libnative and libgreen,
yet still choose which one is used to boot your program. Some breaking changes
you may notice are:
* it's still not possible to easily start up in 1:1 mode - This is fixed by
#11153. In the meantime, you can use #[start] with native::start in order to
boot up in 1:1 mode. Be warned though that the majority of I/O is still
missing from libnative (see PR #11159 for some progress)
https://gist.github.com/8162357
* std::rt::{start, run} are gone - These are temporarily moved into green/native
while #[boot] is getting sorted out. The green/native counterparts perform as
you would expect.
https://gist.github.com/8162372
* std::rt::start_on_main_thread is gone - This function has been removed with no
direct counterpart. As a consequence of refactoring the green/native
libraries, the single threaded spawn mode for a task has been removed (this
doesn't make sense in 1:1 land). This behavior can be restored by directly
using libnative and libgreen. You can use libgreen to spin up a pool of
schedulers and then use libnative for the main task to do things like GUI
management.
https://gist.github.com/8162399
And of course with the removal of some features comes the addition of new ones!
Some new things you may notice are:
* libstd is no longer burdened with libgreen and libnative! This means that the
compile times for libstd should be a little faster, but most notably those
applications only using libstd will have even less code pulled in than
before,
meaning that libstd is that much closer to being used in a bare metal
context. It's still aways off, but we're getting closer every day!
* libgreen has a full-fleged SchedPool type. You can see a bit of how it's used
in gist I posted above. This type is meant to represent a dynamic pool of
schedulers. Right now it's not possible to remove a scheduler from the pool
(requires some more thought and possibly libuv modifications), but you can
add
new schedulers dynamically to the pool.
This type supercedes the ThreadPool type in libextra at this point, and
management of a SchedPool should provide any fine-grained control needed over
the 'M' number in an M:N runtime.
* libgreen and libnative can be used directly to guarantee spawning a green or a
native task, regardless of the flavor of task that is doing the spawning.
In the coming months, I plan on filling out more native I/O to bring it up to
speed with the M:N implementation. I also plan on rewriting the core components
of extra::comm to be performant in both scheduling modes in order to bring the
extra::{comm, arc, sync} primitives up to date with their std::comm
counterparts.
If there are any questions about any of this, feel free to ask me! This thread
is always available, and I'm also reachable as acrichto on IRC or alexcrichton
on github.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Auto-borrow/deref (again, sorry)
On Dec 28, 2013, at 7:10 PM, Vadim vadi...@gmail.com wrote: You could have said Well, I've already declared my variable as mutable, i.e. `let mut i = 0`. Since is already mutable, why do I have to say mut again when borrowing? The compiler could have easily inferred that. I believe the answer is To help readers of this code realize that the called function is [most likely] going to mutate the variable. I believe the same logic should apply to mut references. The answer is because T and mut T are distinct types, with distinct behavior (notably, mutable borrows must be unique). -Kevin___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
