I want to clarify something: post 1.0 does not mean low priority or will
never come to Rust. Post-1.0 means just that: post 1.0. Without taking a
position on this feature in particular, there are many high priority features
slated for post 1.0. Think of 1.0 as a sort of minimum viable product
Hi everyone,
I've submitted a pull request to make captures in closures *by-value* by
default. Previously, they were all by-reference (except for `proc`).
This means that several code patterns will break. Mutating upvars is the
most common pattern:
let mut a = 10;
[ 1i, 2, 3
On 8/19/14 1:05 PM, Patrick Walton wrote:
I've submitted a pull request to make captures in closures *by-value* by
default.
Oh, here's the pull request:
https://github.com/rust-lang/rust/pull/16610
And here's the relevant RFC:
https://github.com/rust-lang/rfcs/blob/master/active/0038
On 8/19/14 1:39 PM, Evan G wrote:
Is there a way to capture some variables by-value, and others
by-reference? The 'ref' syntax you talked about seemed to be only for
the whole argument list, but I might have misunderstood.
If you need more fine-grained control, you can create references
On 7/26/14 5:54 AM, SiegeLordEx wrote:
While this doesn't matter for the pow function (the alternate function
would just have a different path/name), it matters for the special
syntaxes. When the Iterator is no longer enough for you (there was a
case like this in IRC recently involving mutable
On 7/25/14 6:26 AM, Gregor Cramer wrote:
And so the function call is as expected, like with other numeric types:
pow(a) // a is BigInt
But there is now a problem in this function definition, BigInt is given as
a copy, and this is a software design issue (superfluous memory allocation).
And
On 7/25/14 4:43 AM, SiegeLordEx wrote:
Yes, I concur on most of these points and I've brought up some related
points before. The operator overloading technique used by Rust is
antithetical to efficient generic code. The core numeric traits and
functions are currently designed only with built-in
On 7/25/14 10:11 AM, Oscar Boykin wrote:
Did I miss a point in this thread where using a typeclass/trait to
implement exponentiation was dismissed?
This function could be changed to:
fn powT: HasPow(base: T, exp: uint) - T { base.pow(exp) }
trait HasPow {
fn pow(self: Self, exp: uint) -
On 7/25/14 10:10 AM, Josh Haberman wrote:
On Fri, Jul 25, 2014 at 10:04 AM, Patrick Walton pcwal...@mozilla.com wrote:
Neither auto-ref or ad-hoc operator overloading
would let you write a generic function that calls
`pow` and works optimally with both bigints and
ints. I think the only thing
On 7/25/14 3:20 PM, Josh Haberman wrote:
Got it. So the ad hoc part refers to having a template parameter, but
not being able to check its capabilities/interface at template
parsing/typechecking time, it sounds like?
Right. (The term comes from Making Ad-Hoc Polymorphism Less Ad-Hoc,
which is
On 7/25/14 8:26 PM, Patrick Walton wrote:
Uniform value representations work well too (as
OCaml shows), but of course you'll pay a performance cost for that.
Oh, note that Greg's notes are a little bit out of date when discussing
the performance tradeoffs of uniform value representation
On 7/24/14 3:46 PM, Gregor Cramer wrote:
Probably in this case it might be a solution to move pow() into a trait, but
I'm speaking about a general problem. Rust 1.0 will be released, and someone
is developing a new module for version 1.1. But some of the functions in 1.0
are inadequate for the
On 7/22/14 10:16 AM, Lionel Parreaux wrote:
I'm not sure whether this is a big problem in practice, but I was
wondering if it would be possible to switch to some runtime mechanism in
cases like this. Maybe we could make a special version of every generic
functions, that takes a dictionary at
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
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
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
before they will copy.
Patrick
On July 20, 2014 7:39:35 PM PDT, David Henningsson di...@ubuntu.com wrote:
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
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
Because of JavaScript, basically.
Patrick
On July 11, 2014 9:21:20 PM PDT, 范长春 changchun@qq.com wrote:
Hi Rust designers,
I'm curious why rust uses colon : instead of assignment = when
initialize an object. What is the rationale behind this?
From what I see, `Point { x = 2, y = 3 }`
On 7/9/14 7:42 AM, Bob Ippolito wrote:
This seems like madness. No other programming language out there that
I've seen requires developers to mangle these environment variables.
Note that rpath never worked on Windows [1], so it could never be a
long-term solution.
Patrick
[1]:
On 7/9/14 7:42 AM, Bob Ippolito wrote:
This seems like madness. No other programming language out there that
I've seen requires developers to mangle these environment variables.
Also, when installing Rust you don't have to mangle these environment
variables, since the libraries will be placed
On 7/5/14 1:43 PM, Phil Dawes wrote:
Hello!
I was surprised to find the following compile and run without any bother:
#[deriving(Show)]
pub enum MyEnum {
Path
}
fn main() {
let p = Path::new(/filepath/);
let p2 = Path;
println!({},p.as_str());
println!({},p2);
}
%
On 7/5/14 2:06 PM, Phil Dawes wrote:
Thanks Patrick, that makes sense.
I need to think about how to code this into Racer. Can I assume that
anything preceding a :: in a path is from the type namespace?
Yes.
(Is there somewhere other than the rustc source where I should be
reading about
On 7/2/14 11:08 PM, Igor Bukanov wrote:
So at some future point it would be possible to replace
TypedArena_instance().alloc(X) with box(TypedArena_instance) X
avoiding an extra move of X from a temporary allocated on the stack
that the compiler in general cannot optimize?
Yes. Under the hood,
On 7/2/14 11:09 PM, Rob Meijer wrote:
I've been trying to read up on Rust a little bit, and things look really
amazing. Given the focus on 'safety' and the strong link between safety
and integrity related issues, I was intrigued by the following question:
how far would Rust be removed from
On 6/27/14 1:31 AM, Igor Bukanov wrote:
This bug would be harmless in safe code in Rust as exploiting it
requires array access without bound checking.
Correct. This is a prime example of what I was talking about in my
earlier message: weaponizing integer overflows is much more difficult in
a
On 6/23/14 1:55 PM, Daniel Micay wrote:
It's not much a systems language if it's slower than an inner loop in a
JavaScript program without going out of your way to avoid the overhead.
I agree with your general concerns, but I should nitpick that it won't
be slower than JavaScript, since JS
On 6/23/14 2:04 PM, comex wrote:
On Mon, Jun 23, 2014 at 4:49 PM, Daniel Micay danielmi...@gmail.com wrote:
I don't understand what the problem would be with my proposal to have
either `checked { }` or checked operators + a lint for unchecked usage.
I don't see 'checked { }' anywhere in the
On 6/21/14 9:00 AM, Benjamin Striegel wrote:
I don't think that is untenable, performance wise, after all it is
what everyone is currently doing in C++.
We have already made several decisions that will disadvantage us with
regard to C++.
...Like what?
This thread has a lot of very
Why can't you use Rc or Weak? That seems self-evidently false to me:
there are many languages that *only* have reference counting, and they
can represent graphs just fine.
Patrick
___
Rust-dev mailing list
Rust-dev@mozilla.org
On 6/21/14 4:05 PM, Cameron Zwarich wrote:
Another big problem with implicit copy constructors is that they make it
very difficult to write correct unsafe code. When each use of a variable
can call arbitrary code, each use of a variable can trigger unwinding.
You then basically require people to
On 6/21/14 4:10 PM, Daniel Micay wrote:
http://ref.x86asm.net/coder64.html
I don't see enough gaps here for the necessary instructions.
I think all that Intel would have to do is to resurrect INTO (0xce) and
optimize the case in which INTO immediately follows an overflowable
arithmetic
On 6/22/14 2:12 PM, Cameron Zwarich wrote:
For some applications, Rust’s bounds checks and the inability of rustc
to eliminate them in nontrivial cases will already be too much of a
performance sacrifice. What do we say to those people? Is it just that
memory safety is important because of its
On 6/22/14 5:34 PM, Vadim Chugunov wrote:
Modern C++ compilers often have a bunch of runtime checks (stack
overflow protectors, iterator invalidation detectors, and so on) that
may be enabled or disabled, and nobody bats an eye at that.
I'm not so sure. C++ is notoriously bad at dynamic
On 6/22/14 8:46 PM, Daniel Micay wrote:
It's for faster (but not free) array bounds checking. I don't think Rust
will be able to use it because it unwinds on out-of-bounds rather than
aborting, and it will be difficult to turn the OS support (perhaps
SIGFPE / SIGSEGV on *nix) into well defined
On 6/22/14 8:52 PM, Patrick Walton wrote:
On 6/22/14 8:46 PM, Daniel Micay wrote:
It's for faster (but not free) array bounds checking. I don't think Rust
will be able to use it because it unwinds on out-of-bounds rather than
aborting, and it will be difficult to turn the OS support (perhaps
On 6/20/14 11:02 AM, Josh Haberman wrote:
Is there any reasonable scenario under which the compiler could decide
to allocate stack space to cache that lookup, so that the code above
would be optimized to only perform one lookup?
LLVM will do this if it can see the definition of `contains_key`
On 6/20/14 12:07 PM, Paulo Sérgio Almeida wrote:]
Currently being Copy equates with being Pod. The more time passes and
the more code examples I see, it is amazing the amount of ugliness that
it causes. I wonder if there is a way out.
Part of the problem is that a lot of library code assumes
On 6/19/14 4:59 AM, SiegeLord wrote:
Regardless, bignum and linear-algebra are prime candidates for operator
overloading, but the way it is done now by most implementations is just
unsatisfactory. Maybe bignums in std::num and all the linear algebra
libraries could be converted to use a lazy
On 6/16/14 7:32 AM, Sebastian Gesemann wrote:
Assuming this RFC is accepted: How would I have to implement Add for a
custom type T where moving doesn't make much sense and I'd rather use
immutable references to bind the operands?
You don't implement Add for those types.
The purpose of
On 6/16/14 3:17 PM, Cameron Zwarich wrote:
I stated the right case, but the wrong reason. It’s not for
vectorization, it’s because it’s not easy to reuse the storage of a
matrix while multiplying into it.
Wouldn't most matrices be implicitly copyable (and thus optimized--or at
least
I have filed RFC #118 for this:
https://github.com/rust-lang/rfcs/pull/118
Patrick
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
On 6/12/14 1:02 AM, Tommi wrote:
On 2014-06-11, at 16:27, SiegeLord slab...@aim.com
mailto:slab...@aim.com wrote:
So, I think the situation is pretty bad. What can be done to fix it?
I agree that this seems like a serious regression from C++. If it won't
be fixed, I think I'll rather stick
On 6/11/14 6:27 AM, SiegeLord wrote:
So, I think the situation is pretty bad. What can be done to fix it?
Seems to me we can just make the overloaded operator traits take
by-value self.
Patrick
___
Rust-dev mailing list
Rust-dev@mozilla.org
You could just clone the value to get around that error.
On June 12, 2014 10:03:40 AM PDT, Tommi rusty.ga...@icloud.com wrote:
On 2014-06-12, at 19:08, Patrick Walton pcwal...@mozilla.com wrote:
On 6/11/14 6:27 AM, SiegeLord wrote:
So, I think the situation is pretty bad. What can be done
On 6/12/14 10:46 AM, Tommi wrote:
`Copy` types aren't really relevant to a discussion about adding to
Rust the C++ like optimization of moving rvalues (of non-Copy types)
when they're passed to certain functions.
There's nothing to add to Rust. Rust supports moves.
Patrick
On 6/12/14 11:15 AM, Tommi wrote:
On 2014-06-12, at 20:59, Corey Richardson co...@octayn.net
mailto:co...@octayn.net wrote:
Implicit cloning is a non-starter. Clones can be very expensive.
Hiding that cost is undesirable and would require adding Clone to the
language (it's currently a normal
On 6/6/14 6:40 AM, Diggory Hardy wrote:
Dear List,
I want to use strings as map keys, but couldn't find any mention of this
in my understanding common use-case. The following works but as far as I
understand requires a copy of the potential key to be made to call
`contains()`, is this correct?
On 6/2/14 12:44 AM, Tommi wrote:
In my original post I stated that it feels like there's something wrong
with the language when it doesn't allow multiple mutable references to
the same data, but I didn't really explain why it feels like that. So, I
just want to add this simple example to help
On 5/31/14 10:36 AM, Tommi wrote:
It certainly feels like a failure of the Rust type system that you
cannot have multiple mutating references to the same variable when
the variable is accessed only from a single thread. I know the reason
for this is to prevent iterator invalidation, but this is
On 5/31/14 2:44 PM, Tommi wrote:
I don't understand that last sentence. How could you use `transmute` in
safe code given that it's an `unsafe` function?
I mean you could *write* transmute in safe code. Look:
fn my_transmuteT:Clone,U(value: T, other: U) - U {
let mut x =
of mut; (e) it allows uninitialized data to be read,
introducing undefined behavior into the language. I don't think it's worth it.
Patrick
On May 31, 2014 4:42:10 PM PDT, Tommi rusty.ga...@icloud.com wrote:
On 2014-06-01, at 1:02, Patrick Walton pcwal...@mozilla.com wrote:
fn
, at 5:01 PM, Patrick Walton pwal...@mozilla.com
wrote:
I assume what you're trying to say is that we should allow multiple
mutable references to pointer-free data. (Note that, as Huon pointed
out, this is not the same thing as the Copy bound.)
That is potentially plausible, but (a) it adds more
On 5/30/14 8:02 AM, Tommi wrote:
The manual says that the precedence of `as` operator is lower than
that of the binary `*` operator. Thus I would not expect the
following to compile (but it does):
let a: u16 = 1; let b: u32 = 2;
let r = a * b as u16;
Since multiplication is supposed to have
Exceptions, and stack unwinding in general, are not acceptable in many
systems projects. Many, perhaps most, C++ projects turn off exceptions.
This is true of all browser engines I know of, as well as games and OS
kernels--essentially the niches where C++ is the strongest. The primary
reason
On 5/28/14 5:38 PM, Oleg Eterevsky wrote:
7. The usage of mut is a bit confusing. It is supposed to be used as a
qualifier for a variable, but it quickly becomes a part of the type,
when you define functions like
fn test(something: mut Something)
Maybe it makes sense move mut their? Or
You can use extern Rust fn (or ||:'static) to achieve something like C++03
member function pointers without the lifetimes. Attacking Rust without asking
first how to do this is unappreciated.
In the future, unboxed closures will make callbacks easier.
I am opposed to function overloading and
On 5/1/14 6:53 AM, Malthe Borch wrote:
In Rust, the built-in std::str type is a sequence of unicode
codepoints encoded as a stream of UTF-8 bytes.
Meanwhile, building on experience with Python 2 and 3, I think it's
worth considering a more flexible design.
A string would be essentially a rope
On 4/23/14 7:09 PM, Niko Matsakis wrote:
If we just made y a pointer to x, we'd be in trouble.
Well, not if the mutation to x is also done by making it a pointer to
the scratch space occupied by `something_else()`.
Patrick
___
Rust-dev mailing
On 4/24/14 8:16 AM, Bill Myers wrote:
Nice, but why isn't the LLVM optimizer removing the move?
Is it lack of proper alias analysis?
Sounds like that is a separate issue worth pursuing.
LLVM's MemCpyOptimizer is pretty badly ordered in the pipeline and needs
to be rewritten.
In any case, I
Hi everyone,
I believe that by-move pattern bindings don't actually have to perform
any copying of bits for non-word-sized values. This applies to both
`let` and `match`. It surprised me too, which is why I thought I'd send
it to the mailing list first.
A by-move pattern binding is any
On 4/16/14 5:39 PM, Frank Huang wrote:
Second somewhat related question: why can't I write this?
fn main() {
let mut v = Vec::new();
v.push(10);
// get last item
let n = v.get_mut(v.len()-1);
println!(item = {}, *n);
}
For this program, the compiler complains at the line with
Hi everyone,
I'd like to remove the `~foo` literal syntax for owned strings in both
expressions and patterns. After dynamically sized types, this syntax is
the last remnant of the strange parser behavior by which the parser does
something different for `~foo` and `~(foo)` (i.e. by which it
On 4/10/14 10:17 PM, comex wrote:
On Thu, Apr 10, 2014 at 2:28 PM, Alex Crichton a...@crichton.co wrote:
[1] -
https://github.com/rust-lang/rfcs/blob/master/active/0003-opt-in-builtin-traits.md
Off topic, but sigh... first private fields, now this to add even more
verbosity to declaring a
Try this:
On 4/5/14 1:55 PM, Frank Huang wrote:
implT: Writer MySerialization for T {
fn write_my_string(mut self, s: str) - IoResult() {
...
}
}
impl StructToBeSerialized {
fn save_to(self, mut writer: mut io::Writer) - io::IoResult() {
On 4/2/14 9:25 AM, Daniel Micay wrote:
On 02/04/14 11:35 AM, Alex Crichton wrote:
I've noticed recently that there seems to be a bit of confusion about the fate
of ~[T] with an impending implementation of DST on the horizon. This has been
accompanied with a number of pull requests to completely
On 4/2/14 2:51 PM, Huon Wilson wrote:
Specifically, I don't see any concrete positives to doing this for
library functions other than lets keep using ~[T] and ~[T] [T]
having the same in-memory representation (covered below).
Under any scheme I can think of, there are negatives:
1. without
This is essentially what ASan already does, AFAIK. I would like ASan support
for Rust someday, as unsafe code can still benefit from it (although not to the
degree that C code does, obviously).
Patrick
On March 29, 2014 6:44:08 PM PDT, David Morris davidrowlandmor...@gmail.com
wrote:
Might it
On 3/28/14 5:25 AM, Tommi wrote:
On 28 Mar 2014, at 05:56, Patrick Walton pcwal...@mozilla.com wrote:
I think that Rust should give you the ability to opt out of safety, but on a
per-operation basis. Having it as a compiler option is too much of a
sledgehammer: often you want some non
I'm uninterested in features that make Rust memory unsafe outside of the
unsafe sublanguage, and so (as I said in the thread) I am strongly opposed to
the noboundscheck flag or any other similar features.
Patrick
On March 28, 2014 8:12:36 PM PDT, Tony Arcieri basc...@gmail.com wrote:
I really
On 3/27/14 1:42 PM, Tommi wrote:
On 27 Mar 2014, at 22:17, Steve Klabnik st...@steveklabnik.com wrote:
Why isn't there a compiler flag like 'noboundscheck' which would disable all
bounds checking for vectors? It would make it easier to have those language
performance benchmarks (which people
On 3/24/14 11:46 PM, Nick Cameron wrote:
Currently we forbid bounds on type parameters in structs, enums, and
types. So the following is illegal:
struct SX: B {
f: ~TX,
}
IIRC Haskell allows bounds on type parameters (and we did once too), but
I heard that considered deprecated and not
On 3/24/14 2:45 AM, Richo Healey wrote:
I get a compile error:
src/repository.rs:24:17: 24:54 error: expected constant expr for vector
length: non-constant path in constant expr
src/repository.rs:24 cvar_cache: [GitCvarValue, ..
GIT_CVAR_CACHE_MAX] // git_cvar_value
On 3/23/14 12:11 AM, Phil Dawes wrote:
On Sun, Mar 23, 2014 at 2:04 AM, Patrick Walton pcwal...@mozilla.com
mailto:pcwal...@mozilla.com wrote:
Why not change the signature of `search_crate` to take `~str`?
Patrick
Hi Patrick,
The main reason I haven't done this is that it is already
On 3/23/14 9:04 AM, Clark Gaebel wrote:
I think the biggest case for gotos is jumping out of nested loops. Does
rust have a nice way of doing that yet?
There's labeled break and continue. Use `'foo:` to denote a label. (The
reason that we use lifetime syntax there is that eventually it may be
On 3/23/14 2:19 PM, Ziad Hatahet wrote:
You wouldn't probably use this for each and every method, but what it
gives you is Go-style duck typing.
Sure you can define a trait, but what if the struct you to pass to your
function does not implement it? I guess you would have to implement a
wrapper
On 3/18/14 3:31 PM, Andrew C. Morrow wrote:
I work at MongoDB and we often host technology meetups, including the
NYC C++ meetup (http://www.meetup.com/nyccpp/), at our midtown NYC
office. Perhaps we can offer space for an NYC Rust meetup sometime? Or
maybe have an NYC C++ meetup about Rust?
On 3/13/14 6:00 AM, Benjamin Striegel wrote:
Is it correct for me to assume that, even if accepted, virtual things
will be behind a feature flag for 1.0? If so, then I think that will be
enough friction to cause library authors to favor traits instead,
especially if users of
On 3/13/14 11:35 AM, Daniel Micay wrote:
Existing problems with the language aren't a reason to add new problems.
I don't think the coercion is much of a problem; at least, not a fixable
one. Dot notation for method syntax in a systems language that supports
values pretty much requires some
On 3/13/14 11:44 AM, Jan Klesnil wrote:
I am following Rust only for few month. Was the alternate syntax
Trait::method(object, other parameters) discussed?
It will be sometimes useful to write Clone::clone(x) instead of
x.clone() or (x as Clone).clone().
Yup! That's what we call Uniform
On 3/12/14 3:29 AM, Nathan Myers wrote:
Given such primitives, esoteric constructions like virtual inheritance
could be left to ambitious users.
We did sketch a macro-based solution for this that was basically what
you said. It involved an `rtti!()` macro that allowed construction of
vtables
On 3/12/14 2:24 AM, Maciej Piechotka wrote:
+ impl with potentially partial methods? Is the 'all nodes consuming
same amount of memory' too much memory?
Yes, that's too much memory. You see this in rustc actually. rustc uses
a similar structure and AST nodes take up too much memory, leading
On 3/12/14 7:16 AM, Bill Myers wrote:
However, the extensibility of trait objects comes at the cost of fat
pointers, which can be a problem if you have a lot of pointers.
This is fixable without introducing virtual functions, by adding a
way to express Struct and vtable for impl Trait for
It's not as dire as you suggest. We can just allow some further passes to
continue if earlier passes fail. We have this ty_err infrastructure in place
already. Parsing creating an incomplete AST is also possible.
I don't really think that Go is that much easier to do completion on. Type
On 3/12/14 12:33 PM, Daniel Micay wrote:
Rust is already a large language, and the interactions between many of
the features are subtle or poorly defined.
Citation? Like what?
There's a complexity cost for
every feature that's added. It gets harder for a single programmer to
learn the
On 3/12/14 2:59 PM, Daniel Micay wrote:
Traits aren't really any simpler than this. Templates don't produce nice
errors and require the type checker to redo work on each instantiation,
but I don't think the implementation/specification is more complex.
Templates are more complex because of
On 3/11/14 1:42 PM, Daniel Micay wrote:
Existing object systems like COM, DOM and gobject are worth looking at,
but Rust shouldn't bend over backwards to support them. They're legacy
technologies and while interacting with them is important, I don't think
it should result in any extra complexity
On 3/11/14 12:09 PM, Bill Myers wrote:
I see a proposal to add virtual struct and virtual fn in the
workweek meeting notes, which appears to add an exact copy of Java's
OO system to Rust.
I think however that this should be carefully considered, and
preferably not added at all (or failing that,
On 3/11/14 1:42 PM, Daniel Micay wrote:
Traits already provide a choice between monomorphization and virtual
function tables. I hope that the existing system can be extended in an
orthogonal way. I would be very disappointed if Rust ended up like C++,
where you have two almost completely
On 3/11/14 2:09 PM, SiegeLord wrote:
On 03/11/2014 04:52 PM, Brian Anderson wrote:
Fortunately, this feature is independent of others and we can feature
gate it until it's right.
I think that's the crux of the issue some have with this. If a whole
another, completely disjoint path for
On 3/11/14 2:15 PM, Maciej Piechotka wrote:
Could you elaborate on DOM? I saw it referred a few times but I haven't
seen any details. I wrote simple bindings to libxml2 dom
(https://github.com/uzytkownik/xml-rs - warning - I wrote it while I was
learning ruby) and I don't think there was a
On 3/11/14 2:19 PM, Haoyi Li wrote:
FWIW, C# requires that you mark overridable functions *virtual*, the
opposite of Java where you need to mark un-overridable functions
*final*. The Scala community is coming to the same conclusion that
unrestricted overriding is pretty dangerous. It's similar
wrote:
On Tue, 2014-03-11 at 14:18 -0700, Patrick Walton wrote:
On 3/11/14 2:15 PM, Maciej Piechotka wrote:
Could you elaborate on DOM? I saw it referred a few times but I
haven't
seen any details. I wrote simple bindings to libxml2 dom
(https://github.com/uzytkownik/xml-rs - warning - I
Dereference of a null pointer is memory-unsafe due to being undefined behavior.
You can't count on dereference of nullptr resulting in a load of address zero:
the optimizer is free to (and often does) remove that load and any code
following it. This means that, for example, clang will
wrote:
On Wed, Mar 5, 2014 at 11:42 PM, Patrick Walton pwal...@mozilla.com
wrote:
Dereference of a null pointer is memory-unsafe due to being undefined
behavior. You can't count on dereference of nullptr resulting in a
load of
address zero: the optimizer is free to (and often does) remove
On 3/3/14 11:00 PM, Nathan Myers wrote:
My concern is that the examples presented in tutorials must be
compelling to skilled C++ programmers. If we fail to win them over, the
whole project will have been a waste of time. The most skilled
C++ programmers know all too well what mistakes show up
On 3/4/14 11:43 AM, John Mija wrote:
I'm supposed that a linker could be built to link that intermediate file
together to a Rust program.
Just use cgo to call Rust.
Patrick
___
Rust-dev mailing list
Rust-dev@mozilla.org
You are only considering the simplest uses of references. Consider iterator
invalidation, deletion of the object referenced by the this pointer,
truncation of a vector containing an object to which references are live, etc.
C++ references are not memory safe and no compiler warnings can make
On 3/3/14 5:51 PM, Daniel Micay wrote:
Smart pointers and destructors are no more unsafe in C++ than they are
in Rust. Rust makes moves and references safe, it doesn't do anything to
make a smart pointer implementation more safe.
It prevents you from misusing smart pointers and destructors to
1 - 100 of 608 matches
Mail list logo
