Devs, please explain how such option could decrease the safety of the
language. As it would be just that, an option, an opt-in one.
IMHO it even could increase the safety of Rust. There are some extreme
optimizing C++ programmers currently. Yes, they are a small fraction, but
they exist. And they
On 29/03/14 08:53 AM, Zoltán Tóth wrote:
Devs, please explain how such option could decrease the safety of the
language. As it would be just that, an option, an opt-in one.
IMHO it even could increase the safety of Rust. There are some extreme
optimizing C++ programmers currently. Yes, they
On 2014.03.29 13:53:49 +0100, Zoltán Tóth wrote:
Devs, please explain how such option could decrease the safety of the
language. As it would be just that, an option, an opt-in one.
As somebody else said before, rust's indexing operator is like C++'s
std::vector::at() which throws an exception
2014-03-29 21:53 GMT+09:00 Zoltán Tóth zo1...@gmail.com:
Use 'unsafe' everywhere?
Yes, using the `unsafe fn` in place of `fn` everywhere should be
sufficient. Actually it is not very hard to do so (before writing this
I have experimented with my own project for this strategy and it only
had a
Thank Björn Steinbrink for your example. Though Daniel already mentioned
the key [the difference between the runtime and logic errors] earlier
many times, I only now understood it from the example.
Sorry
___
Rust-dev mailing list
Rust-dev@mozilla.org
Might it be useful to turn this the other way up, and introduce an option
to *add* bounds checks to unsafe indexing when debugging? It seems like
removing that undefined behaviour would make debugging of unsafe code
easier, like the optional bounds checks for unsafe programming languages
that
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 28/03/14 03:48, Daniel Micay wrote:
On 27/03/14 11:04 PM, Tommi Tissari wrote:
Case by case is all fine and good. But you're trying argue what a programmer
*should* do if he knew what was good for him.
Rust doesn't view the programmer as an infallible, trusted entity.
Actually, I believe
On 28 Mar 2014, at 05:48, Daniel Micay danielmi...@gmail.com wrote:
I don't know about those other dialects.
You're proposing introducing new dialect of Rust.
In Crust, code generating a failure on out-of-bounds will now cause
silent memory corruption. Crust will do away with safety
On 28/03/14 22:04, Lee Braiden wrote:
On 28/03/14 03:48, Daniel Micay wrote:
On 27/03/14 11:04 PM, Tommi Tissari wrote:
Case by case is all fine and good. But you're trying argue what a
programmer *should* do if he knew what was good for him.
Rust doesn't view the programmer as an infallible,
On 28/03/14 07:04 AM, Lee Braiden wrote:
On 28/03/14 03:48, Daniel Micay wrote:
On 27/03/14 11:04 PM, Tommi Tissari wrote:
Case by case is all fine and good. But you're trying argue what a
programmer *should* do if he knew what was good for him.
Rust doesn't view the programmer as an
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-performance-critical bounds to be
On 28/03/14 08: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
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
We don't WANT that though. Haven't you been reading? If we need that flag
to perform as well as C++, we'll have failed in our mission. We don't just
want to make a safe language: we want to make one safe, fast, and
concurrent.
Also, as Daniel pointed out, the stdlib already relies heavily on
A good plus for rust here is that in general, the idiomatic way to access
arrays in a loop doesn't use bounds checking. For example, to write a dot
product in c++ you'd do this:
double dot(const double* x, const double* y, int len) {
double result = 0.0;
for(int i = 0; i len; ++i)
result
On 28/03/14 07:44 AM, Tommi wrote:
This is incorrect. All those range based functions (or majority of
them... I'm not sure) are safe if the range(s) you pass to them is safe.
That's why those range functions can't guarantee safety as part of their
signature. For example, look at the following
On 28 Mar 2014, at 14:27, Daniel Micay danielmi...@gmail.com wrote:
On 28/03/14 08: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
On 28/03/14 23:49, Tommi wrote:
On 28 Mar 2014, at 14:27, Daniel Micay danielmi...@gmail.com wrote:
On 28/03/14 08: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
If your hotspot is spread across thousands and thousands of lines of code, you
have made major architectural mistakes.
On 28 Mar 2014, at 12:49, Tommi rusty.ga...@icloud.com wrote:
On 28 Mar 2014, at 14:27, Daniel Micay danielmi...@gmail.com wrote:
On 28/03/14 08:25 AM, Tommi wrote:
On
On 28 Mar 2014, at 15:01, Huon Wilson dbau...@gmail.com wrote:
[..] And anyway, as Daniel and Patrick say, if you don't need the utmost
safety, then Rust isn't the language you're looking for: things like C++ work
well in the speed department, at the cost of safety
Yes, it seems that Rust
It just seems that all arguments have been made 5+ times by both sides. I
would agree that mailing list discussions that start going in circles
become no longer appropriate for a mailing list.
On Fri, Mar 28, 2014 at 7:48 AM, Tommi rusty.ga...@icloud.com wrote:
On 28 Mar 2014, at 15:43,
I would just like to interject that this conversation has been blowing my
inbox up all morning and seems to be going absolutely nowhere. The people
on both sides of this issue have stated their arguments exhaustively, and I
neither believe that the Rust developers would ever introduce a flag that
On 28/03/14 15:31, Sanghyeon Seo wrote:
To defend rustc's honor: rustc has no such design issues.
That's my favourite part of this whole thread. Really. :D
--
Lee
___
Rust-dev mailing list
Rust-dev@mozilla.org
On 28 Mar 2014, at 17:46, Erick Tryzelaar erick.tryzel...@gmail.com wrote:
Disagreement is fine [..]
I would think that to be an axiom which didn't need to be mentioned.
What I think this whole discussion boils down to, is orthodoxy vs. pragmatism.
The pragmatic think that wiggle room is
On 28 Mar 2014, at 14:47, Daniel Micay danielmi...@gmail.com wrote:
On 28/03/14 07:44 AM, Tommi wrote:
This is incorrect. All those range based functions (or majority of
them... I'm not sure) are safe if the range(s) you pass to them is safe.
That's why those range functions can't guarantee
On 28 Mar 2014, at 15:43, Matthew Frazier leafstormr...@gmail.com wrote:
I would just like to interject that this conversation has been blowing my
inbox up all morning and seems to be going absolutely nowhere.
That's a good argument against using mailing lists for this kind of a purpose.
Do not close this thread. This is actually the most exciting one currently.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
On Thu, Mar 27, 2014 at 1:17 PM, Steve Klabnik st...@steveklabnik.comwrote:
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
It seems like, prior to even proposing
On 28/03/14 09:52 PM, Tony Arcieri wrote:
On Thu, Mar 27, 2014 at 1:17 PM, Steve Klabnik st...@steveklabnik.com
mailto: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
On Fri, Mar 28, 2014 at 6:55 PM, Daniel Micay danielmi...@gmail.com wrote:
You can already use unchecked indexing in any case where there's a
performance issue so I don't really understand what the fuss is about.
Confirm. This entire thread seems like much ado about nothing.
--
Tony Arcieri
On Fri, Mar 28, 2014 at 8:14 AM, Daniel Micay danielmi...@gmail.com wrote:
Lifetimes serve no purpose other than to prevent the programmer from
doing stuff, and are *entirely* stripped out before code generation. Do
you want to override/disable borrow checking and freezing too?
There's also
On 29/03/14 12:10 AM, comex wrote:
On Fri, Mar 28, 2014 at 8:14 AM, Daniel Micay danielmi...@gmail.com wrote:
Lifetimes serve no purpose other than to prevent the programmer from
doing stuff, and are *entirely* stripped out before code generation. Do
you want to override/disable borrow
On Sat, Mar 29, 2014 at 12:19 AM, Daniel Micay danielmi...@gmail.com wrote:
This is unfair. You're mixing up static checks such as
exhaustiveness, freezing, and lifetimes, which have no performance
impact (or at least, the performance impact caused by their
limitations would be mitigated only
On 29/03/14 12:36 AM, comex wrote:
On Sat, Mar 29, 2014 at 12:19 AM, Daniel Micay danielmi...@gmail.com wrote:
This is unfair. You're mixing up static checks such as
exhaustiveness, freezing, and lifetimes, which have no performance
impact (or at least, the performance impact caused by their
On Sat, Mar 29, 2014 at 12:41 AM, Daniel Micay danielmi...@gmail.com wrote:
A lot of code in the compiler simply leaves out error checking and
relies on getting an ICE from the failure. It would take a long time to
translate everything into proper error messages.
Well, a compiler should not
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 are bound to make with no bounds
I think your hypothetical situation of saving millions by disabling
bounds checks is absurd: To save $10 per machine, assuming $0.20 per
kilowatt-hour, and saving 50 nanojoules per bounds check, you'd need
to be avoiding about 10^14 check. That's equivalent to avoiding 1
million bounds checks
I think the point is that the compiler should not be forcing people to
do things, but enabling people to do things, with sensible defaults.
Personally, whilst I would advocate MORE bounds checking in rust for
debugging / prototyping purposes, I don't think bounds checking is even
ideal. It's
Alternatively, in this future where people are deploying Rust
applications to hundreds of thousands of servers, we could be using
Intel's Memory Protection Extensions for much cheaper bounds checking
etc. Which surely other applications will be using once bounds checks
are nearly free. Rust will
It's not about debugging, it's about memory safety. It'd be ridiculous
to disable bounds checking just because you've done QA. How many
security exploits are over- or under-flows?
On Thu, Mar 27, 2014 at 7:16 PM, Lee Braiden leebr...@gmail.com wrote:
I think the point is that the compiler should
a) I think Rust is making a mistake by considering boundary checks only
on memory accesses
b) No, it really wouldn't be ridiculous, if you've checked it properly
at a QA stage. By definition, it's ridiculous to KEEP checking it, once
it's already been checked thoroughly, as a proper QA
On Thu, Mar 27, 2014 at 4:51 PM, Lee Braiden leebr...@gmail.com wrote:
b) No, it really wouldn't be ridiculous, if you've checked it properly at
a QA stage. By definition, it's ridiculous to KEEP checking it, once it's
already been checked thoroughly, as a proper QA process would do.
I'm
On 27/03/14 07:16 PM, Lee Braiden wrote:
I think the point is that the compiler should not be forcing people to
do things, but enabling people to do things, with sensible defaults.
Personally, whilst I would advocate MORE bounds checking in rust for
debugging / prototyping purposes, I don't
On 27/03/14 04:42 PM, Tommi wrote:
A flag that removes safety is pretty antithical to the goals of the
language, IMHO.
Yes, I agree it's not the official Rust way of things. But not providing the
option seems quite totalitarian. An example use case might be a company that
runs its code
Compiling with that flag would figuratively speaking wrap everything inside an
unsafe block and then omit vector bounds checking. The flag wouldn't be allowed
for library builds.
What I find a bit totalitarian about this situation is that the language forces
a decision which the programmer
On 27/03/14 09:02 PM, Tommi Tissari wrote:
Compiling with that flag would figuratively speaking wrap everything inside
an unsafe block and then omit vector bounds checking. The flag wouldn't be
allowed for library builds.
What I find a bit totalitarian about this situation is that the
Oh, ok, well in that case I suppose the flag should cause all indexing
operations to become their unsafe variants instead, all functions that call
those to become unsafe, etc. propagating the unsafety where it's needed to make
the code compile.
On 28 Mar 2014, at 03:15, Daniel Micay
Opting in case by case is not the same thing as having a compiler flag which
you can toggle without modifying the source.
Perhaps bounds checking is the only safety measure which has runtime penalty?
(Not sure about that) But that would explain why it would be a separate flag.
By the way, D
On 27/03/14 10:04 PM, Tommi Tissari wrote:
Opting in case by case is not the same thing as having a compiler flag which
you can toggle without modifying the source.
A case-by-case basis preserves the safety guarantees of the language and
doesn't introduce a new dialect. It also means you can
On 03/27/2014 10:04 PM, Tommi Tissari wrote:
By the way, D is memory safe (although it's opt-in) and it has this
noboundscheck flag. So I don't see what the problem is.
Rust takes a very different stance to safety than to D (e.g. making it
safe by default). In the D community my perception
On 28 Mar 2014, at 03:41, Jeffery Olson olson.jeff...@gmail.com wrote:
forces a decision which the programmer should be allowed to make for
himself. A bit like someone dictating my hair style.
Yes. Rust is just like hair salon that forbids you from setting your own hair
on fire.
If you want sharp scissors, use unsafe indexing. You generally don't need
it everywhere, just in your inner loop.
Profile, then optimize. Rust gives you the tools needed to optimize where
things get hot, but we also like safety by default.
- Clark
On Thu, Mar 27, 2014 at 10:31 PM, Tommi
Case by case is all fine and good. But you're trying argue what a programmer
*should* do if he knew what was good for him. While I'm trying to argue that
the programmer should be *free* to test how fast his code would run without
bounds checking, just for the hell of it. You want to enforce
On 27/03/14 11:04 PM, Tommi Tissari wrote:
Case by case is all fine and good. But you're trying argue what a programmer
*should* do if he knew what was good for him.
Rust doesn't view the programmer as an infallible, trusted entity. This
is clear in the design of lifetimes. For example,
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
I'd like to point out that I agree with your central premise that most
bounds checks are useless. Some huge percentage of them, in fact.
But I still enjoy the peace of mind that they bring. If I actually need a
piece of code to be manually checked, covered in tests, and benchmarked to
be fast,
On 27/03/14 11:56 PM, Clark Gaebel wrote:
I'd like to point out that I agree with your central premise that most
bounds checks are useless. Some huge percentage of them, in fact.
In my opinion, this isn't necessarily true for Rust. Iterators provide a
lot of functionality without the overhead
58 matches
Mail list logo
