5 ms·

The thing is, with current tooling, the current design means that I can write a function, type a key combination, and have the type signature printed in a buffe

The thing is, with current tooling, the current design means that I can write a function, type a key combination, and have the type signature printed in a buffer (where I can then copy it into place). And until I do that, there is warning highlighting on the function. Now in some ways this may seem silly - are you really going to understand code without understanding types? But especially for people new to the language, _or_ when you're dealing with new libraries (if you've ever written a little wrapper around a function from a complicated library, you know what I mean), it's nice to choose whether you want to work from values or from types (where undefined is your friend). Which isn't to say that think rust's decision is bad, just that having flexibility makes this kind of tooling easier (and I'm assuming here that in all cases, the end result will be all annotated top level functions). And, part of rust's choice was probably to make type checking easier, which is an important thing (especially given how sophisticated the borrow checker is).

burntsushi 12y ago
Interesting point. Getting the type annotation inferred for you there is definitely useful. I've used it a few times myself. The `undefined` trick is also immensely useful. I use it a lot when starting a new module. Rust also has a notion of bottom, indicated by `!`, which will unify with all types. I frequently use this in Rust in a similar way that I use `undefined` in Haskell. (In Rust, you would speak `fail!()` or `unreachable!()` or `unimplemented!()` or define-your-own.) > (if you've ever written a little wrapper around a function from a complicated library, you know what I mean) Yes, absolutely. I haven't really run into this problem with Rust yet though. Types are generally pretty simple. If and when Rust gets higher-kinded types, that would assuredly change.
- fanf2 12y ago
  I thought ! in Rust indicates a macro.
  - burntsushi 12y ago
    A `!` followed by an identifier does, yes. But a `!` also lets you define diverging functions: fn diverging() -> ! { unreachable!() } The two `!` in that code are completely orthogonal things. See the manual on diverging functions: http://doc.rust-lang.org/rust.html#diverging-functions http://doc.rust-lang.org/rust.html#diverging-functions
tel 12y ago
> Now in some ways this may seem silly Not at all! Typing should be a conversation with the compiler. If you have a strong understanding of what you are writing then, yes, writing the types first makes sense. On the other hand, sometimes I only understand how some particular pieces fit together—at this point, I want the compiler to throw its inference engine at my code fragment and tell me everything it can! Typing and programming is exactly the same as theorem stating and proving in mathematics. It would be idiotic to have one-way information flow only. That said, it's also practically criminal to just hand someone a proof without stating what you think it's supposed to be proving. Ultimately, that it where you must wind up.

burntsushi 12y ago

Interesting point. Getting the type annotation inferred for you there is definitely useful. I've used it a few times myself. The `undefined` trick is also immensely useful. I use it a lot when starting a new module. Rust also has a notion of bottom, indicated by `!`, which will unify with all types. I frequently use this in Rust in a similar way that I use `undefined` in Haskell. (In Rust, you would speak `fail!()` or `unreachable!()` or `unimplemented!()` or define-your-own.) > (if you've ever written a little wrapper around a function from a complicated library, you know what I mean) Yes, absolutely. I haven't really run into this problem with Rust yet though. Types are generally pretty simple. If and when Rust gets higher-kinded types, that would assuredly change.

fanf2 12y ago
I thought ! in Rust indicates a macro.
- burntsushi 12y ago
  A `!` followed by an identifier does, yes. But a `!` also lets you define diverging functions: fn diverging() -> ! { unreachable!() } The two `!` in that code are completely orthogonal things. See the manual on diverging functions: http://doc.rust-lang.org/rust.html#diverging-functions http://doc.rust-lang.org/rust.html#diverging-functions

tel 12y ago

> Now in some ways this may seem silly Not at all! Typing should be a conversation with the compiler. If you have a strong understanding of what you are writing then, yes, writing the types first makes sense. On the other hand, sometimes I only understand how some particular pieces fit together—at this point, I want the compiler to throw its inference engine at my code fragment and tell me everything it can! Typing and programming is exactly the same as theorem stating and proving in mathematics. It would be idiotic to have one-way information flow only. That said, it's also practically criminal to just hand someone a proof without stating what you think it's supposed to be proving. Ultimately, that it where you must wind up.