• bearophile (19/27) Nov 19 2014 It shows the tradeoffs of static enforcement of memory safety in
• Andrei Alexandrescu (4/8) Nov 19 2014 Why did this redditor say it's a horrific hack?
• deadalnix (6/17) Nov 19 2014 Too much time spent commenting, not enough time spent coding ?
• Vladimir Panteleev (4/14) Nov 19 2014 Probably because it performs extra work (which may or may not be
• bearophile (17/19) Nov 19 2014 For me it's a nice construct, it's something unsafe that the

"bearophile" <bearophileHUGS lycos.com> writes:

It shows the tradeoffs of static enforcement of memory safety in 
Rust:

http://cglab.ca/~abeinges/blah/rust-lifetimes-and-collections/

Some quotations:

However it's fairly easy to make an incorrect program by 
overflowing an integer. Some would therefore assert that it 
should be unsafe to add two integers together. However "being 
able to write an incorrect program" isn't what Rust cares about. 
That's impossible to guarantee with any amount of analysis, 
static or dynamic, unless you hate mathematicians. Rust 
specifically constrains itself to memory safety.<

This shows the weak typing of Rust, and its weak static analysis 
of valid index intervals:


let mut v = vec![1i32, 2, 3, 4, 5];
for i in range(0, v.len()) {
     // Array litteral syntax will just crash the program if you 
index out of bounds,
     // instead of returning an Option.
     let x = &mut v[i];
     // do some work with x
}

That's all perfectly sound and good, but it's wasting tons of 
time doing bounds checking! It's also totally unidiomatic.<


This is nice:

 fn split_at_mut(&mut self, mid: uint) -> (&mut [T], &mut [T]);

Bye,
bearophile

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 11/19/14 8:54 AM, bearophile wrote:
 This is nice:

 fn split_at_mut(&mut self, mid: uint) -> (&mut [T], &mut [T]);

 Bye,
 bearophile

Why did this redditor say it's a horrific hack? 
http://www.reddit.com/r/programming/comments/2mqyd3/rust_lifetimes_and_collections/cm6yj7b

Andrei

"deadalnix" <deadalnix gmail.com> writes:

On Wednesday, 19 November 2014 at 17:58:01 UTC, Andrei
Alexandrescu wrote:
 On 11/19/14 8:54 AM, bearophile wrote:
 This is nice:

 fn split_at_mut(&mut self, mid: uint) -> (&mut [T], &mut [T]);

 Bye,
 bearophile

 Why did this redditor say it's a horrific hack? 
 http://www.reddit.com/r/programming/comments/2mqyd3/rust_lifetimes_and_collections/cm6yj7b

 Andrei

Too much time spent commenting, not enough time spent coding ?
That is a useful construct and that is a nice example of how a
nicely encapsulated unsafe construct (with a safe interface) can
lead to interesting new constructs.

"Vladimir Panteleev" <vladimir thecybershadow.net> writes:

On Wednesday, 19 November 2014 at 17:58:01 UTC, Andrei 
Alexandrescu wrote:
 On 11/19/14 8:54 AM, bearophile wrote:
 This is nice:

 fn split_at_mut(&mut self, mid: uint) -> (&mut [T], &mut [T]);

 Bye,
 bearophile

 Why did this redditor say it's a horrific hack? 
 http://www.reddit.com/r/programming/comments/2mqyd3/rust_lifetimes_and_collections/cm6yj7b

Probably because it performs extra work (which may or may not be 
optimized out) just so it fits in Rust's safety model.

"bearophile" <bearophileHUGS lycos.com> writes:

Andrei Alexandrescu:

 Why did this redditor say it's a horrific hack? 
 http://www.reddit.com/r/programming/comments/2mqyd3/rust_lifetimes_and_collections/cm6yj7b

For me it's a nice construct, it's something unsafe that the 
compiler has to "assume" for correct. In a language, unless you 
want a system like Agda/Coq and you have enough time and brain to 
write down all proofs, you have limits in what you can express. 
Sometimes you have to go outside those constraints for various 
practical reasons, especially in a system language. But I think 
the unsafety of split_at_mut is all self-contained and you can't 
go into unsafe territory using it in safe blocks (unlike D things 
like assumeUnique).

Modern languages are better also because the size of the zone 
that the compiler can prove as correct is larger. And future 
languages, with little steps will probably increase such zones, 
without going to full manual formal proof, that is an excessive 
burden for most cases for most programmers.

Bye,
bearophile