On Thu, Jan 2, 2014 at 1:06 AM, Vadim wrote:
>
> And let's not forget about the heap-allocated objects, which start out as
> pointers in the first place.
Unique pointers have value semantics so this shouldn't be relevant to
the visibility of mutation. The consensus is already to remove the
auto-
On 1/1/14 10:06 PM, Vadim wrote:
Well, since requiring '&' at the original borrow site doesn't really
prevent the "unexpected mutability" problem, why not drop it and
eliminate a bunch of noise from Rust sources?
But it does eliminate mutation of lvalues.
And, again, if
"unexpected mutability
Everyone is entitled to their own opinions. However, those opinions should
be expressed in a polite manner. Phrases such as "Choice he (since its
mostly men)" and "mentally masturbate" do not seem to foster a welcoming,
inclusive environment. Quoting from
https://github.com/mozilla/rust/wiki/Note-d
On Wed, Jan 1, 2014 at 9:12 PM, Patrick Walton wrote:
> There is no "real answer" beyond the one I already gave: that we are
> already precisely as explicit as C, that Rust references do not actually
> have the hidden mutation hazard of C++ references, and that changing would
> place the language
> Deciding to reuse wrong, but mainstream, design decisions in one's own
> language
> is deciding to intentionally make it of lower quality. !!! Funny (read: mad),
> isn't it? It is thus also intentionally deciding to make it not worth success.
> This, apparently, to make its actual chances of suc
On 01/02/2014 12:05 AM, György Andrasek wrote:
The proper way to support a language in CMake is outlined in
`Modules/CMakeAddNewLanguage.txt`:
I was guided away from that method by this email:
http://www.cmake.org/pipermail/cmake/2011-March/043444.html . My
approach is amenable to generating
On 1/1/14 9:13 PM, Palmer Cox wrote:
To me, this doesn't sound as much like a proposal for a change in syntax
as a proposal to remove a bit of magic that Rust is currently doing. I
don't know that I'm necessarily in favor or that though, since it would
certainly make code more wordy. That wordine
I could be pretty wrong, so if I am, I apologize and please ignore. Anyway,
I thought I once read somewhere that when you call a function defined like:
fn foo(a: &mut int) { ... }
with code that looks like
fn bar(b: &mut int) {
foo(b);
}
that despite what it looks like, you aren't really pa
There is no "real answer" beyond the one I already gave: that we are already
precisely as explicit as C, that Rust references do not actually have the
hidden mutation hazard of C++ references, and that changing would place the
language in a different space entirely. Please don't suggest that I a
The proper way to support a language in CMake is outlined in
`Modules/CMakeAddNewLanguage.txt`:
This file provides a few notes to CMake developers about how to add
support for a new language to CMake. It is also possible to place
these files in CMAKE_MODULE_PATH within an outside project to add
I think the real answer is "at this point nobody wants to tweak basic Rust
syntax yet again". See the other thread about Rust roadmap, etc. Oh
well...
On Wed, Jan 1, 2014 at 3:49 PM, Martin Olsson wrote:
> Short version of my question:
>
> Why doesn't rust require "mut" param prefix at call
On 1/1/14 8:26 PM, SiegeLord wrote:
(Posting this here as I think it might be useful for some but I don't
feel like getting a Reddit account and there's no rust-announce).
I've been experimenting with building Rust crates using some established
build systems, focusing on SCons and CMake due to t
(Posting this here as I think it might be useful for some but I don't
feel like getting a Reddit account and there's no rust-announce).
I've been experimenting with building Rust crates using some established
build systems, focusing on SCons and CMake due to their popularity.
Neither turned ou
On Wed, Jan 1, 2014 at 6:49 PM, Martin Olsson wrote:
> Short version of my question:
>
> Why doesn't rust require "mut" param prefix at call sites? i.e. to avoid
> "non-const ref badness" that C++ has?
Well, to be somewhat extreme, in a function like
struct S { a: &mut int, b: &mut int }
fn f(s:
On 1/1/14 3:55 PM, Patrick Walton wrote:
Because that would work completely like any other language with pointers
that I know of.
Err, I mean "unlike".
Patrick
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
On 1/1/14 3:49 PM, Martin Olsson wrote:
For example in C the call "f(a,&b);" might modify "b" but not "a" so the
"&" token acts as a "call site heads-up flag" when reading the code.
Same in Rust.
In
C# the "out/ref" keywords are mandatory at the call site if the callee
uses them in its param
Short version of my question:
Why doesn't rust require "mut" param prefix at call sites? i.e. to
avoid "non-const ref badness" that C++ has?
Longer version of my question:
Since this question was asked recently by vadim and not really
answered clearly (imo), I'm also including this longer
On Dec 31, 2013, at 7:40 PM, Jason Fager wrote:
> If you're pushing to an unbounded vec in a tight loop you've got fundamental
> design issues.
Or you’re processing user input. A rather trivial example here is parsing a
file into lines. If I have 2GB of RAM and I throw a 4GB file at that parse
On 12/31/2013 01:41 PM, Patrick Walton wrote:
On 12/31/13 1:33 PM, Nathan Myers wrote:
>>
The possibility of precisely defining the behavior of a bounded
channel in all circumstances is what makes it suitable as a
first-class primitive.
Unbounded channels have defined behavior as well. Undefi
On 12/31/2013 01:41 PM, Patrick Walton wrote:
> Bounded channels can be constructed from unbounded channels as well,
> so I don't see how this is an argument for making bounded channels
> the primitive.
Sometimes we need an indefinite-precision integer, other times a
fixed-size integer. Sometimes
20 matches
Mail list logo
