bstrie: you're right it is a trade off, but I don't agree that its not
worth it. We're talking about non-atomic incrementing of an integer - that
is pretty much the cheapest thing you can do on a processor (not free of
course, since caching, etc., but still very cheap). I've programmed a lot
in
On 21/06/14 02:06 AM, Nick Cameron wrote:
bstrie: you're right it is a trade off, but I don't agree that its not
worth it. We're talking about non-atomic incrementing of an integer -
that is pretty much the cheapest thing you can do on a processor (not
free of course, since caching, etc., but
I found all the clone()s in Rust unpleasant, it really put me off using ref
counting.
Excellent. ;)
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
On Jun 20, 2014, at 11:06 PM, Nick Cameron li...@ncameron.org wrote:
zwarich: I haven't thought this through to a great extent, and I don't think
here is the right place to plan the API. But, you ought to still have control
over whether an Rc pointer is copied or referenced. If you have an
In :
http://www.reddit.com/r/rust/comments/2581s5/informal_survey_which_is_clearer_mutability_or/
http://smallcultfollowing.com/babysteps/blog/2014/05/13/focusing-on-ownership/
https://air.mozilla.org/guaranteeing-memory-safety-in-rust/
there was talk of renaming mut. What is the current
I guess I forgot that C++ ref counted pointers (pre-11) generally have a
move version of the type. Thanks for pointing that out.
I agree it would be odd to copy that design (Rc/RcTemp) in a language which
has move semantics by default. I wonder if we could come up with _some_
design that would be
On Fri, Jun 20, 2014 at 11:06 PM, Nick Cameron li...@ncameron.org wrote:
I found all the clone()s in Rust unpleasant, it really put me off using
ref counting.
I consider that to be a feature, not a bug.
Given that this is something C++ programmers coming to Rust will be used
to using, I
Regarding the white-listing, I also find it weird, but should the user
experience be worse just because Rc and Arc are implemented in Rust and so
we should do nothing in the name of orthogonality? A user won't care if Arc
and Rc are built-in or not.
I may have passed the message that its only
It should not need to be said, but I am not advocating (over)using Rc, Gc,
or Arc. One should start by BoxT and T. But when this is not enough,
using the other pointer types should not be a pain. More than a pain, I
would not like to have unpleasant surprises when I find out that Box is not
As far as I am aware, using theorem proving tools[1] to provide limits on value
ranges is pretty
hard and often computationally intensive to do in /simple/ code. I've only seen
prototype systems
where the user is expected to write full contracts on exactly how every
function may modify
every
On Sat, Jun 21, 2014 at 5:18 AM, Diggory Hardy diggory.ha...@unibas.ch wrote:
As far as I am aware, using theorem proving tools[1] to provide limits on
value ranges is pretty hard and often computationally intensive to do in
simple code. I've only seen prototype systems where the user is
On Sat, Jun 21, 2014 at 5:10 AM, Nick Cameron li...@ncameron.org wrote:
I wonder if we could come up with _some_
design that would be better than the current one.
Could always pave the road to hell and have a short postfix operator.
It would have to be only for cheap clones, but frankly I think
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++. When we have the opportunity to do better, performance-wise,
than C++, we must seize it in order to
A user won't care if Arc and Rc are built-in or not.
They will definitely care, once they attempt to write their own pointer
types and find that they're second-class citizens compared to the types
that have been blessed by the compiler. There's little point in having a
powerful and extensible
For those of you coming today, my train has been delayed multiple times, so I
will be a few minutes late. I'll be wearing a bright red Ruby shirt, because
that's funny and also more noticeable.
See you all soon!
___
Rust-dev mailing list
Wish I could join you guys.
Hack beautifully. Be safe from evil.
On Jun 21, 2014 12:46 PM, Steve Klabnik st...@steveklabnik.com wrote:
For those of you coming today, my train has been delayed multiple times,
so I will be a few minutes late. I'll be wearing a bright red Ruby shirt,
because
On Jun 21, 2014 12:46 PM, Steve Klabnik st...@steveklabnik.com wrote:
For those of you coming today, my train has been delayed multiple times,
so I will be a few minutes late. I'll be wearing a bright red Ruby shirt,
because that's funny and also more noticeable.
See you all soon!
Already
On 21 June 2014 11:10, Nick Cameron li...@ncameron.org wrote:
I wonder if we could come up with _some_
design that would be better than the current one.
The reason the ugliness is the repeated clone calls:
let x = Rc::int::new(1);
...
foo(x.clone());
bar(x.clone());
As far as I am aware, using theorem proving tools[1] to provide limits on value
ranges is pretty
hard and often computationally intensive to do in /simple/ code. I've only seen
prototype systems
where the user is expected to write full contracts on exactly how every
function may modify
every
On Sat, Jun 21, 2014 at 1:52 PM, Igor Bukanov i...@mir2.org wrote:
Another possibility is to allow for move-in-move-out params that moves
the the value back to the caller when the function returns forcing the
callee to use the clone call if it wants to store the argument for a
later use.
It
RcT introduces useless indirection that not only clatters the code
with x but also harms performance as the compiler cannot eliminate
that when calling across crates.
On 21 June 2014 21:24, comex com...@gmail.com wrote:
On Sat, Jun 21, 2014 at 1:52 PM, Igor Bukanov i...@mir2.org wrote:
Another
This is assuming that foo and bar are fn(RCint), right?
In normal use I would expect them to be fn(int) ot fn(int), unless they
need to retain a reference. And in the latter case I would make them
fn(mut RCint) and clone() internally.
On Sat, Jun 21, 2014 at 10:52 AM, Igor Bukanov i...@mir2.org
On 20 June 2014 21:07, Paulo Sérgio Almeida pssalme...@gmail.com wrote:
I have seen many other examples, where the code could mislead the reader into
thinking there are several, e.g., Mutexes:
let mutex = Arc::new(Mutex::new(1));
let mutex2 = mutex.clone();
Does this experience exist outside
I am assuming that people will use Rc not out of choice, but when they have
to. We can trust our users to use ownership and references where possible,
after all these are the easiest things to use, and privileged in all the
Rust docs and tutorials. We will still need style guides in Rust and we
My 2c:
The world is finally becoming security-conscious, so I think it is a only
matter of time before architectures that implement zero-cost integer
overflow checking appear. I think we should be ready for it when this
happens. So I would propose the following practical solution (I think
Gabor
On Jun 21, 2014, at 5:50 AM, Gregory Maxwell gmaxw...@gmail.com wrote:
On Sat, Jun 21, 2014 at 5:18 AM, Diggory Hardy diggory.ha...@unibas.ch
wrote:
As far as I am aware, using theorem proving tools[1] to provide limits on
value ranges is pretty hard and often computationally intensive to do
On 21/06/14 05:21 PM, Vadim Chugunov wrote:
My 2c:
The world is finally becoming security-conscious, so I think it is a
only matter of time before architectures that implement zero-cost
integer overflow checking appear. I think we should be ready for it
when this happens. So I would
On Sat, Jun 21, 2014 at 2:42 PM, Daniel Micay danielmi...@gmail.com wrote:
ARM and x86_64 aren't going anywhere and it's too late for trap on
overflow to be part of the baseline instruction set. It's far from a
sure thing that it would even be added.
Having watched the debacle that was Azul
On 21/06/14 05:47 PM, Tony Arcieri wrote:
On Sat, Jun 21, 2014 at 2:42 PM, Daniel Micay danielmi...@gmail.com
mailto:danielmi...@gmail.com wrote:
ARM and x86_64 aren't going anywhere and it's too late for trap on
overflow to be part of the baseline instruction set. It's far from a
On Sat, Jun 21, 2014 at 6:02 PM, Daniel Micay danielmi...@gmail.com wrote:
It's not possible to add new instructions to x86_64 that are not large
and hard to decode. It's too late, nothing short of breaking backwards
compatibility by introducing a new architecture will provide trapping on
On Sat, Jun 21, 2014 at 2:42 PM, Daniel Micay danielmi...@gmail.com wrote:
On 21/06/14 05:21 PM, Vadim Chugunov wrote:
My 2c:
The world is finally becoming security-conscious, so I think it is a
only matter of time before architectures that implement zero-cost
integer overflow checking
I agree with Vadim that the world will inevitably become security-conscious
-- also safety-conscious. We will live to see it unless such a bug causes
nuclear war or power grid meltdown.
When the sea change happens, Rust will either be (A)* the attractive choice
for systems programming* or (B)
On Jun 21, 2014, at 2:15 PM, Nick Cameron li...@ncameron.org wrote:
Ownership does not always work, graphs often appear in programming. When they
do, you have to use Rc or Gc to cope. We shouldn't punish programmers who
have these problems to deal with. Telling them to use ownership is
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 write the equivalent of exception-safe
On 21/06/14 06:54 PM, Jerry Morrison wrote:
I agree with Vadim that the world will inevitably become
security-conscious -- also safety-conscious. We will live to see it
unless such a bug causes nuclear war or power grid meltdown.
When the sea change happens, Rust will either be (A)/ the
Agreed. Post-1.0, I hope to put some effort into addressing this.
For now, the best solution I've found is to use borrowed references, arena
allocation and unsafe initialisation. This is far from perfect, and you end
up with _a lot_ of lifetime parameters, but it works if the problem fits
the
On 21/06/14 06:26 PM, comex wrote:
On Sat, Jun 21, 2014 at 6:02 PM, Daniel Micay danielmi...@gmail.com wrote:
It's not possible to add new instructions to x86_64 that are not large
and hard to decode. It's too late, nothing short of breaking backwards
compatibility by introducing a new
On Sat, Jun 21, 2014 at 4:07 PM, Daniel Micay danielmi...@gmail.com wrote:
On 21/06/14 06:54 PM, Jerry Morrison wrote:
I agree with Vadim that the world will inevitably become
security-conscious -- also safety-conscious. We will live to see it
unless such a bug causes nuclear war or power
No one will use Rust if it's slow. If it uses checked arithmetic, it
will be slow. There's nothing subjective about that.
This is the only argument that matters.
If we are slower than C++, Rust will not replace C++ and will have failed
at its goal of making the world a safer place. The world
On 21/06/14 07:27 PM, Jerry Morrison wrote:
On Sat, Jun 21, 2014 at 4:07 PM, Daniel Micay danielmi...@gmail.com
mailto:danielmi...@gmail.com wrote:
On 21/06/14 06:54 PM, Jerry Morrison wrote:
I agree with Vadim that the world will inevitably become
security-conscious -- also
On 21/06/14 07:55 PM, Benjamin Striegel wrote:
No one will use Rust if it's slow. If it uses checked arithmetic, it
will be slow. There's nothing subjective about that.
This is the only argument that matters.
If we are slower than C++, Rust will not replace C++ and will have
failed at its
OK. You folks made good points.
How about if I retract or obsolete in favor of or up for big change or
not the tool for those purposes? Maybe abort-on-overflow in suitable
cases...
On Sat, Jun 21, 2014 at 5:02 PM, Daniel Micay danielmi...@gmail.com wrote:
On 21/06/14 07:55 PM, Benjamin
On Sat, Jun 21, 2014 at 4:55 PM, Benjamin Striegel ben.strie...@gmail.com
wrote:
In addition, bringing up hypothetical CPU architectures with support for
checked arithmetic is not relevant. Rust is a language designed for 2014,
not for 2024.
So why not do the safe thing by default (which
On 21/06/14 08:16 PM, Tony Arcieri wrote:
On Sat, Jun 21, 2014 at 4:55 PM, Benjamin Striegel
ben.strie...@gmail.com mailto:ben.strie...@gmail.com wrote:
In addition, bringing up hypothetical CPU architectures with support
for checked arithmetic is not relevant. Rust is a language
On Sat, Jun 21, 2014 at 7:10 PM, Daniel Micay danielmi...@gmail.com wrote:
Er... since when? Many single-byte opcodes in x86-64 corresponding to
deprecated x86 instructions are currently undefined.
http://ref.x86asm.net/coder64.html
I don't see enough gaps here for the necessary
45 matches
Mail list logo
