Oh, Patrick, I slightly mis-read what you said. Yes, that was the intention.
I think official documentation shouldn't be directly trying to sell Rust
against other languages,
While I agree, comparing against things we already know is a powerful
way to learn. I _do_ think that we shouldn't say
On Mon, Mar 3, 2014 at 8:06 PM, Steve Klabnik st...@steveklabnik.comwrote:
Oh, Patrick, I slightly mis-read what you said. Yes, that was the
intention.
I think official documentation shouldn't be directly trying to sell
Rust against other languages,
While I agree, comparing against things
On 03/03/14 06:06 PM, Steve Klabnik wrote:
Oh, Patrick, I slightly mis-read what you said. Yes, that was the intention.
I think official documentation shouldn't be directly trying to sell Rust
against other languages,
While I agree, comparing against things we already know is a powerful
Then, you could show this in the article, using the good subset of C++.
Then people can choose.
On Mon, Mar 3, 2014 at 10:19 PM, Steve Klabnik st...@steveklabnik.comwrote:
Part of the issue with that statement is that you may or may not
program in this way. Yes, people choose certain subsets
On Mon, Mar 3, 2014 at 10:19 PM, Steve Klabnik st...@steveklabnik.com
wrote:
Part of the issue with that statement is that you may or may not
program in this way. Yes, people choose certain subsets of C++ that
are more or less safe, but the language can't help you with that.
On Mon, Mar 3,
On 03/03/14 08:41 PM, Patrick Walton wrote:
On 3/3/14 4:32 PM, Daniel Micay wrote:
Type-checked lifetimes on references and type-checked move semantics are
examples of true safety improvements over C++. They are not a panacea as
they prevent expressing many safe patterns, even when the safety
On 03/03/14 08:19 PM, Steve Klabnik wrote:
Part of the issue with that statement is that you may or may not
program in this way. Yes, people choose certain subsets of C++ that
are more or less safe, but the language can't help you with that.
You can choose to write unsafe code in Rust too. The
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
When I first wrote this, there was a LARGE amount of discussion on HN.
Here's one particular subthread that seems relevant:
https://news.ycombinator.com/item?id=7052518
It includes a C++11 bit of code with uniq_pointer that crashes.
___
Rust-dev mailing
It's plain hyperbolic to call Rust's unsafe blocks something that leads to a
false sense of security. If you don't want your unsafe code to be reliant on
safe code, don't call that safe code, or be conservative and defend yourself
against it going wrong. Unsafe code should be simple and easy to
On 03/03/2014 05:54 PM, Patrick Walton wrote:
On 3/3/14 5:53 PM, Daniel Micay wrote:
On 03/03/14 08:19 PM, Steve Klabnik wrote:
Part of the issue with that statement is that you may or may not
program in this way. Yes, people choose certain subsets of C++ that
are more or less safe, but the
I recently wrote a tool that helps with auditing unsafe blocks:
https://github.com/huonw/unsafe_ls
It lists all the unsafe blocks in a crate and prints the lines with the
actual unsafe actions on them, with a crude filter to omit FFI (and/or
only see FFI). This doesn't do anything intelligent
On Mon, Mar 3, 2014 at 8:17 PM, Nathan Myers n...@cantrip.org wrote:
(Arguably, BTW, the keyword should be safe, because you are
asserting to the compiler that it should consider what is being
done there to be safe, despite any misgivings it may have, and
challenging the reader to contradict
On Mon, Mar 3, 2014 at 10:17 PM, Nathan Myers n...@cantrip.org wrote:
It's clear that we need someone fully competent in C++ to
code any comparisons. In C++, one is only ever motivated to
(unsafely) extract the raw pointer from a smart pointer when
only a raw pointer will do. This is exactly
On 03/03/2014 07:46 PM, comex wrote:
On Mon, Mar 3, 2014 at 10:17 PM, Nathan Myers n...@cantrip.org wrote:
It's clear that we need someone fully competent in C++ to
code any comparisons. In C++, one is only ever motivated to
(unsafely) extract the raw pointer from a smart pointer when
only a
On Mar 3, 2014, at 8:44 PM, Nathan Myers n...@cantrip.org wrote:
On 03/03/2014 07:46 PM, comex wrote:
On Mon, Mar 3, 2014 at 10:17 PM, Nathan Myers n...@cantrip.org wrote:
It's clear that we need someone fully competent in C++ to
code any comparisons. In C++, one is only ever motivated to
On Mon, Mar 3, 2014 at 11:44 PM, Nathan Myers n...@cantrip.org wrote:
C++ does allow a reference to last longer than the
referent, and that's worth calling attention to.
Yeah... for memory safety I would consider a reference the same thing
as a pointer, although it helps in other cases such as
Tobi, good question!
I see Vladimir already answered, but I'll throw my own answer in too.
I think you can encode HKTs in MPTCs (MPTCs are just relations on types,
HKTs are just functions on types, and functions are specific kind of
relation [you might run into a problem with HKTs being
Incidentally, to the extent this is about a proposed document
comparing Rust's safety to C++ in general
It's actually not: that's incidental. The idea is to communicate the core
ideas of Rust in 30 minutes or less. To give the reader an idea if they'd
like to pursue Rust further.
Memory safety
19 matches
Mail list logo
