Announcing Rust 1.20

Post by dbaupp » Fri, Sep 01, 2017, 12:00 AM UTC

Arkanosis wrote: post #149

steveklabnik wrote: post #96

Earlier quoted context omitted.

You often don't need it at all; fn foo(x: f32) { println!("{}", x); } fn main() { let x = 5.0; foo(x); } It will look at the signature for foo, and infer that x must be f32.

Whoa! Isn't this kind of inference dangerous? It seems that whichever call comes first is used to infer the type, so a single added line of code can change the type of a variable… fn foo32(x: f32) { println!("{}", x); } fn foo64(x: f64) { println!("{}", x); } fn bar64() { let x = 5.0; // f64 foo64(x); foo32(x); } fn bar32() { let x = 5.0; // f32, not f64 foo32(x); foo64(x); }

Post by a_t48 » Fri, Sep 01, 2017, 12:16 AM UTC

Animats wrote: post #133

hashmal wrote: post #118

Earlier quoted context omitted.

I'd take a similar approach. After all `unsafe` use cases include the implementation of data structures.

I've argued this issue before. The answer isn't generics, Coq, or some fancy type system nobody will understand or use properly. There are only a few inherent trouble spots in pure Rust code safety. The big two are: - Partially initialized arrays. "Vec" has to be unsafe because growing an array involves uninitialized slots. You just need a way to say "this array is initialized from 0..N only", where N is in a data st…

Post by __s » Fri, Sep 01, 2017, 12:26 AM UTC

a_t48 wrote: post #153

Animats wrote: post #133

Earlier quoted context omitted.

I've argued this issue before. The answer isn't generics, Coq, or some fancy type system nobody will understand or use properly. There are only a few inherent trouble spots in pure Rust code safety. The big two are: - Partially initialized arrays. "Vec" has to be unsafe because growing an array involves uninitialized slots. You just need a way to say "this array is initialized from 0..N only", where N is in a data st…

A hashmap being implemented on top of vectors is a pretty common implementation. Not sure what Rust uses though.

Post by kibwen » Fri, Sep 01, 2017, 1:00 AM UTC

Arkanosis wrote: post #149

steveklabnik wrote: post #96

Earlier quoted context omitted.

You often don't need it at all; fn foo(x: f32) { println!("{}", x); } fn main() { let x = 5.0; foo(x); } It will look at the signature for foo, and infer that x must be f32.

Whoa! Isn't this kind of inference dangerous? It seems that whichever call comes first is used to infer the type, so a single added line of code can change the type of a variable… fn foo32(x: f32) { println!("{}", x); } fn foo64(x: f64) { println!("{}", x); } fn bar64() { let x = 5.0; // f64 foo64(x); foo32(x); } fn bar32() { let x = 5.0; // f32, not f64 foo32(x); foo64(x); }

    error[E0308]: mismatched types
     --> src/main.rs:7:13
      |
    7 |       foo32(x);
      |             ^ expected f32, found f64
    
    error[E0308]: mismatched types
      --> src/main.rs:13:13
       |
    13 |       foo64(x);
       |             ^ expected f64, found f32

Post by ryl00 » Fri, Sep 01, 2017, 1:22 AM UTC

PopsiclePete wrote: post #128

jmcomets wrote: post #68

Earlier quoted context omitted.

I used to be a huge fan of C++. I loved how you could work with a somewhat OO language while still wielding dark powers like: manual memory management, mix-n-match polymorphism (aka. virtual inheritance ), templates, type-erasing. Then I got a full time job working with a large C++ codebase. Since then I've been dealing with: - uninitialized variables / members - NULL checks - buffer overflows, especially with C-stri…

That's my main beef with C++. You read a book and it's beautiful - no uninitialized memory, safety, no C arrays/strings, RAII everywhere, it's clean, fast.....then you get to the "real world" and realize that 99% of C++ programmers are pretty f###ing horrible at their job and should've just stuck to naked C because at least then you'd be able to pin-point the bugs easier. So C++ is a wonderful language - in a world t…