On 22/06/14 05:09 PM, Rick Richardson wrote:
Apologies if this has been suggested, but would it be possible to have a
compiler switch that can add runtime checks and abort on
overflow/underflow/carry for debugging purposes, but the default
behavior is no check? IMO this would be the best of
On 2014-06-22, at 23:31 , Daniel Micay danielmi...@gmail.com wrote:
On 22/06/14 05:09 PM, Rick Richardson wrote:
Apologies if this has been suggested, but would it be possible to have a
compiler switch that can add runtime checks and abort on
overflow/underflow/carry for debugging purposes,
On 22/06/14 05: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
On 22/06/14 05:48 PM, Masklinn wrote:
On 2014-06-22, at 23:31 , Daniel Micay danielmi...@gmail.com wrote:
On 22/06/14 05:09 PM, Rick Richardson wrote:
Apologies if this has been suggested, but would it be possible to have a
compiler switch that can add runtime checks and abort on
On 22/06/14 06:37 AM, Matthieu Monrocq wrote:
I am not a fan of having wrap-around and non-wrap-around types, because
whether you use wrap-around arithmetic or not is, in the end, an
implementation detail, and having to switch types left and right
whenever going from one mode to the other is
I think a reasonable middle ground is to have checked operators that look a
little funny. Kind of like swift, but in reverse:
malloc((number_of_elements +~ 12) *~ size_of::int())
Where adding a ~ to the end of an operator makes it check for overflow.
This would certainly look nicer than stuff
The PPA nightlies should be up to date now if you're using an Ubuntu
version that's still supported by Canonical (i.e. supported by
Launchpad).
--
Hans Jørgen
On 22 June 2014 19:24, Daniel Fath daniel.fa...@gmail.com wrote:
Are there advantages or disadvantages with using nightlies from the
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 Sun, Jun 22, 2014 at 05:26:47PM -0400, Daniel Micay wrote:
Rust's design is based on the assumption that performance cannot be
achieved simply by having highly optimized inner loops. It takes a whole
program approach to performance by exposing references as first-class
values and
On Sun, Jun 22, 2014 at 11:05 PM, Daniel Micay danielmi...@gmail.com
wrote:
On 22/06/14 09:31 AM, Gábor Lehel wrote:
The prospect of future architectures with cheaper (free) overflow
checking isn't my primary motivation, though if we also end up better
prepared for them as a side effect,
Makes sense, but I am curious, how do you see adding this post-1.0? Would
you:
- add overflow-checked int types and tell everybody to use them instead of
the default ones from that point on
- declare that in Rust2 integers are overflow-checked, and have everybody
port their Rust1 code. (Well,
Apologies for adding heat to the discussion. The industry needs to make
progress on security/safety-critical systems, and Rust does a great deal
for that by bringing memory safety to a C/C++ alternative.
This post about hardware traps for integer overflow
http://blog.regehr.org/archives/1154 is
On Sun, Jun 22, 2014 at 2:31 PM, Daniel Micay danielmi...@gmail.com wrote:
On 22/06/14 05:09 PM, Rick Richardson wrote:
Apologies if this has been suggested, but would it be possible to have a
compiler switch that can add runtime checks and abort on
overflow/underflow/carry for debugging
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 22/06/14 07:43 PM, Vadim Chugunov wrote:
Makes sense, but I am curious, how do you see adding this post-1.0?
Would you:
- add overflow-checked int types and tell everybody to use them instead
of the default ones from that point on
- declare that in Rust2 integers are overflow-checked,
On 22/06/14 07:26 PM, Gábor Lehel wrote:
Coincidentally, I didn't propose it. I proposed one implementation with
owned allocation (which we already have) in the `prelude` and one with
tracing GC allocation in the `gc` module.
Then I don't understand why we would have one for task-local
On 22/06/14 08:25 PM, Jerry Morrison wrote:
The post also links to Wikipedia on Intel MPX
http://en.wikipedia.org/wiki/Intel_MPX: Intel is adding x86 extensions
to aid memory safety! I think it's for array bounds checking, but the
article is unclear.
It's for faster (but not free) array
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 22/06/14 07:24 PM, Andrew Poelstra wrote:
On Sun, Jun 22, 2014 at 05:26:47PM -0400, Daniel Micay wrote:
Rust's design is based on the assumption that performance cannot be
achieved simply by having highly optimized inner loops. It takes a whole
program approach to performance by exposing
On 22/06/14 11: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 22/06/14 06:43 PM, Clark Gaebel wrote:
I think a reasonable middle ground is to have checked operators that
look a little funny. Kind of like swift, but in reverse:
malloc((number_of_elements +~ 12) *~ size_of::int())
Where adding a ~ to the end of an operator makes it check for
On Jun 22, 2014, at 8:52 PM, Patrick Walton pcwal...@mozilla.com 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
On Sun, Jun 22, 2014 at 5:05 PM, Daniel Micay danielmi...@gmail.com wrote:
Anyway, no one has offered an explanation of how they're
planning on integrating this into LLVM and how they propose turning a
trapping operation into unwinding across various platforms.
Isn't that what asynchronous
On 23/06/14 12:17 AM, comex wrote:
On Sun, Jun 22, 2014 at 5:05 PM, Daniel Micay danielmi...@gmail.com wrote:
Anyway, no one has offered an explanation of how they're
planning on integrating this into LLVM and how they propose turning a
trapping operation into unwinding across various
On Mon, Jun 23, 2014 at 12:10 AM, Daniel Micay danielmi...@gmail.com wrote:
Rust only gains efficiency from the type system, not any form of thread
safety that's not available to a garbage collected language. It's able
to send `BoxT` data structures without performing a deep copy.
Which is the
On Mon, Jun 23, 2014 at 12:35 AM, Daniel Micay danielmi...@gmail.com wrote:
An operation that can unwind isn't pure. It impedes code motion such as
hoisting operations out of a loop, which is very important for easing
the performance issues caused by indexing bounds checks. LLVM doesn't
model
On Jun 22, 2014, at 9:35 PM, Daniel Micay danielmi...@gmail.com wrote:
An operation that can unwind isn't pure. It impedes code motion such as
hoisting operations out of a loop, which is very important for easing
the performance issues caused by indexing bounds checks. LLVM doesn't
model the
On 23/06/14 12:49 AM, Cameron Zwarich wrote:
On Jun 22, 2014, at 9:35 PM, Daniel Micay danielmi...@gmail.com
mailto:danielmi...@gmail.com wrote:
An operation that can unwind isn't pure. It impedes code motion such as
hoisting operations out of a loop, which is very important for easing
the
On 23/06/14 12:46 AM, comex wrote:
On Mon, Jun 23, 2014 at 12:35 AM, Daniel Micay danielmi...@gmail.com wrote:
An operation that can unwind isn't pure. It impedes code motion such as
hoisting operations out of a loop, which is very important for easing
the performance issues caused by indexing
On Mon, Jun 23, 2014 at 1:05 AM, Daniel Micay danielmi...@gmail.com wrote:
The call we make to perform unwinding isn't a pure function though, it's
aware of the context causing it to unwind. As long as we're supporting
stuff like backtraces outside of a debugger, that's going to be the case.
On Jun 22, 2014, at 10:00 PM, Daniel Micay danielmi...@gmail.com wrote:
On 23/06/14 12:49 AM, Cameron Zwarich wrote:
On Jun 22, 2014, at 9:35 PM, Daniel Micay danielmi...@gmail.com
mailto:danielmi...@gmail.com wrote:
An operation that can unwind isn't pure. It impedes code motion such as
On 23/06/14 01:15 AM, comex wrote:
On Mon, Jun 23, 2014 at 1:05 AM, Daniel Micay danielmi...@gmail.com wrote:
The call we make to perform unwinding isn't a pure function though, it's
aware of the context causing it to unwind. As long as we're supporting
stuff like backtraces outside of a
On 23/06/14 01:16 AM, Cameron Zwarich wrote:
On Jun 22, 2014, at 10:00 PM, Daniel Micay danielmi...@gmail.com
mailto:danielmi...@gmail.com wrote:
On 23/06/14 12:49 AM, Cameron Zwarich wrote:
On Jun 22, 2014, at 9:35 PM, Daniel Micay danielmi...@gmail.com
mailto:danielmi...@gmail.com
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
Good evening Rust colleagues;
As we discussed at the May Seattle meetup (A success! about 6 people from
larger, smaller, and academic environments visited), we'd like to meetup in
July and talk about our current projects in a quasi-presentation format at
one of the local companies or the
On Mon, Jun 16, 2014 at 09:59:45PM +0100, Vladimir Pouzanov wrote:
Everything works fine up to the point of references. References allow some
nodes to modify other nodes. So, the first pass — I parse that snippet into
PlatformTree/Nodes struct. Second pass — I walk over the tree and for each
On 06/19, Benjamin Striegel wrote:
I'm actually very pleased that floating point literals are entirely
separate from integer literals, but I can't quite explain why. A matter of
taste, I suppose. Perhaps it stems from symmetry with the fact that I
wouldn't want `let x: int = 1.0;` to be valid.
On 06/20/2014 07:36 AM, Nathan Typanski wrote:
On 06/19, Benjamin Striegel wrote:
I'm actually very pleased that floating point literals are entirely
separate from integer literals, but I can't quite explain why. A matter of
taste, I suppose. Perhaps it stems from symmetry with the fact that I
It’s a mistake to write crypto using general-purpose big number libraries. You
usually want crypto code to protect against timing attacks, for example, and
your average big number library aims for performance; the two goals are at odds.
On Jun 19, 2014, at 10:04 PM, Igor Bukanov i...@mir2.org
On 20/06/14 07:36 AM, Nathan Typanski wrote:
On 06/19, Benjamin Striegel wrote:
I'm actually very pleased that floating point literals are entirely
separate from integer literals, but I can't quite explain why. A matter of
taste, I suppose. Perhaps it stems from symmetry with the fact that I
Does Rust have any way of optimizing away repeated calls to the same
function where possible? Like GCC's pure function attribute?
To get a little more crazy, say you're working with a Map. Sometimes it's
convenient to write code like this:
if (map.contains_key(foo)) {
let val =
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 20/06/14 02:02 PM, Josh Haberman wrote:
Does Rust have any way of optimizing away repeated calls to the same
function where possible? Like GCC's pure function attribute?
To get a little more crazy, say you're working with a Map. Sometimes
it's convenient to write code like this:
if
Hi all,
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.
There are two aspects regarding Copy: the semantic side and the
implementation side. On the more
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
I'm not a fan of the idea of blessing certain types with a compiler-defined
whitelist. And if the choice is then between ugly code and copy
constructors, I'll take ugly code over surprising code.
On Fri, Jun 20, 2014 at 3:10 PM, Patrick Walton pcwal...@mozilla.com
wrote:
On 6/20/14 12:07 PM,
On Wed, Jun 18, 2014 at 8:20 PM, Daniel Micay danielmi...@gmail.com wrote:
On 18/06/14 01:08 PM, Gábor Lehel wrote:
# Exposition
We've debated the subject of integer overflow quite a bit, without much
apparent progress. Essentially, we've been running in circles around two
core facts:
On Wed, Jun 18, 2014 at 10:05 PM, Gregory Maxwell gmaxw...@gmail.com
wrote:
On Wed, Jun 18, 2014 at 10:08 AM, Gábor Lehel glaebho...@gmail.com
wrote:
memory safety bugs.) This is a step up from C's insanity of undefined
behavior for signed overflow, where the compiler assumes that overflow
On Wed, Jun 18, 2014 at 10:19 PM, Daniel Micay danielmi...@gmail.com
wrote:
On 18/06/14 03:40 PM, comex wrote:
On Wed, Jun 18, 2014 at 1:08 PM, Gábor Lehel glaebho...@gmail.com
wrote:
To partially address this, once we have tracing GC, and if we manage to
make
`GcT: Copy`, we should add
On Thu, Jun 19, 2014 at 9:05 AM, Jerry Morrison jhm...@gmail.com wrote:
Nice analysis!
Over what scope should programmers pick between Gábor's 3 categories?
The wraparound is desired category should only occur in narrow parts of
code, like computing a hash. That suits a wraparound-operator
This weekend I'll be moving the Rust buildbot master and bors over to a
new machine. There will be some downtime but otherwise no new changes.
That is all.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
On Fri, Jun 20, 2014 at 2:07 PM, Gábor Lehel glaebho...@gmail.com wrote:
On Thu, Jun 19, 2014 at 9:05 AM, Jerry Morrison jhm...@gmail.com wrote:
Nice analysis!
Over what scope should programmers pick between Gábor's 3 categories?
The wraparound is desired category should only occur in
On Sat, Jun 21, 2014 at 1:37 AM, Jerry Morrison jhm...@gmail.com wrote:
On Fri, Jun 20, 2014 at 2:07 PM, Gábor Lehel glaebho...@gmail.com wrote:
On Thu, Jun 19, 2014 at 9:05 AM, Jerry Morrison jhm...@gmail.com wrote:
Nice analysis!
Over what scope should programmers pick between
On Fri, Jun 20, 2014 at 5:36 PM, Gábor Lehel glaebho...@gmail.com wrote:
On Sat, Jun 21, 2014 at 1:37 AM, Jerry Morrison jhm...@gmail.com wrote:
On Fri, Jun 20, 2014 at 2:07 PM, Gábor Lehel glaebho...@gmail.com
wrote:
On Thu, Jun 19, 2014 at 9:05 AM, Jerry Morrison jhm...@gmail.com
On Wed, Jun 18, 2014 at 10:08 AM, Gábor Lehel glaebho...@gmail.com wrote:
core facts: wrapping is bad, but checking is slow. The current consensus
On this point, has anyone tried changing the emitted code for all i32
operations to add trivial checks, hopefully in a way that llvm can
optimize out
1001 - 1100 of 8896 matches
Mail list logo
