Some notes on Rust

Post by masklinn » Sun, Feb 01, 2015, 7:01 PM UTC

falcolas wrote: post #7

stebalien wrote: post #6

I don't have an account there so I'll comment here: > In particular, allocating a new object and returning a reference to it it from a function is common in C++ but difficult in Rust, because the function doing the allocation doesn't know the expected lifetime of what it returns. This is what boxes are for. A Box is a unique pointer to a value on the heap and can be used without knowing compile-time lifetimes. Refere…

> References and lifetimes allow you to safely return pointers to stack allocated objects. This is explicitly called out as non-idiomatic behavior in the documentation, however. The preferred action is to allocate on the caller's heap and pass a mutable reference down to the callee. In fact, in general it's recommended not to use Box, because it complicates human reasoning about the code. And while it gets around a l…

Post by falcolas » Sun, Feb 01, 2015, 7:25 PM UTC

burntsushi wrote: post #35

falcolas wrote: post #31

Earlier quoted context omitted.

> Explicit returns are not frowned upon. I don't know where you got that idea From the docs: http://doc.rust-lang.org/book/functions.html > Using a `return` as the last line of a function works, but is considered poor style

Yes. Which is what I said. "Using a `return` as the last line of a function works" is not the same as "don't use explicit returns."

    fn something... {
      match input {
      Ok(input_val) => {/* several lines of semicolon terminated code*/
                        output}
      Err(errval) => {/* several more lines of semicolon terminated code */
              output}
    } 

    fn something... {
      match input {
      Ok(input_val) => {/* several lines of semicolon terminated code*/
                        return output;}
      Err(errval) => {/* several more lines of semicolon terminated code */
              return output;}
    } 

    fn something... {
      match input {
      Ok(input_val) => {/* several lines of semicolon terminated code*/
                        output;}
      Err(errval => {/* several more lines of semicolon terminated code */
              output;}
    } 

Post by alkonaut » Sun, Feb 01, 2015, 7:37 PM UTC

Post by mafribe » Sun, Feb 01, 2015, 8:01 PM UTC

steveklabnik wrote: post #5

gcv wrote: post #4

Rust's error handling looks like the Maybe monad. That seems pretty reasonable in Haskell. I'm a little surprised by the criticism in the article — is the author saying there isn't enough syntactic sugar?

It's similar. We don't have HKT, so we can't get fully generic monads, but you can implement specific instances, like we have with Option/Result.

Post by steveklabnik » Sun, Feb 01, 2015, 8:07 PM UTC

mafribe wrote: post #47

steveklabnik wrote: post #5

Earlier quoted context omitted.

It's similar. We don't have HKT, so we can't get fully generic monads, but you can implement specific instances, like we have with Option/Result.

Steve, what's the reason that Rust doesn't have HKTs (higher-kinded types). Is there a technical barrier, e.g. to do with life-time inference, or is it a philosophical choice not to have them?