6 ms·

It is presented here that name before type is easier to read as a matter of fact. I’m not so sure. In math or languages where type info is optional, we often wr

It is presented here that name before type is easier to read as a matter of fact. I’m not so sure. In math or languages where type info is optional, we often write “x = 5”. When type info is required, it is natural to evolve to “int x = 5”. Readers would naturally focus on the latter part. When we write “x: int = 5”, the type info is in the middle. We cannot skip it even when we just want to focus on the name and value.

andrewla 6y ago
Many languages allow you to elide the type, which is another nice thing about the type following the identifier. In Scala, in particular, types are not the assigned type like in C (where they also serve as the storage specification) -- they are assertions, that the compiler will check are compatible with the code. So `val x: int = "hello"` is no good and the compiler can cut it short right there; this is especially useful as call-site documentation.
- throwanem 6y ago
  Conversely, a lot of languages will infer type from first assignment, so in e.g. TypeScript "let x = 5", x is inferentially typed as 'number' and the type checker will throw if the implicit constraint is later violated. This reduces the need for explicit type annotations, clearing up a lot of the visual and cognitive noise.
- dastbe 6y ago
  There is still a distinction between primitives and object types in Scala, so it's not correct to say that types in Scala aren't used for storage specification. It's also the case that there are plenty of languages where all types imply storage specification and they support plenty of type elision.
skybrian 6y ago
If you have local type inference, an alternative would be "x = 5: int".
- nyanpasu64 6y ago
  In Rust, you can write: let x = 5i32; Sadly it's nowhere near as elegant for string literals.
  - littlestymaar 6y ago
    > Sadly it's nowhere near as elegant for string literals. What do you mean? For string literals you just do let foo= "bar"; and that's it. BTW, in Rust you can omit most variable type annotations since the compiler is able to infer them. You have to give type annotations to functions though.
    - nyanpasu64 6y ago
      I meant turning string literals into heap-allocated strings.
      - littlestymaar 6y ago
        Ah yes, in this case it's indeed a bit more verbose: let foo= "bar".to_string(); It's on purpose though, because Rust likes to make heap allocations explicit, and I find it fine to be honest, but you mileage may vary.
        nyanpasu64 6y ago
        https://users.rust-lang.org/t/to-string-vs-to-owned-for-string-literals/1441 https://users.rust-lang.org/t/to-string-vs-to-owned-for-stri... > I’m more fond of using .into(). It requires adding type hints in some cases, but for most cases it is shorter than the alternatives. Especially when passing a string literal to a function that requires String. > Now that specialization for str::to_string() has landed, we can safely say that to_string() has the same performance as to_owned(), and thus to_string() should be used since it’s more clear > I now strongly prefer to_owned() for string literals over either of to_string() or into(). yay language complexity

andrewla 6y ago

Many languages allow you to elide the type, which is another nice thing about the type following the identifier. In Scala, in particular, types are not the assigned type like in C (where they also serve as the storage specification) -- they are assertions, that the compiler will check are compatible with the code. So `val x: int = "hello"` is no good and the compiler can cut it short right there; this is especially useful as call-site documentation.

throwanem 6y ago
Conversely, a lot of languages will infer type from first assignment, so in e.g. TypeScript "let x = 5", x is inferentially typed as 'number' and the type checker will throw if the implicit constraint is later violated. This reduces the need for explicit type annotations, clearing up a lot of the visual and cognitive noise.
dastbe 6y ago
There is still a distinction between primitives and object types in Scala, so it's not correct to say that types in Scala aren't used for storage specification. It's also the case that there are plenty of languages where all types imply storage specification and they support plenty of type elision.

skybrian 6y ago

If you have local type inference, an alternative would be "x = 5: int".

nyanpasu64 6y ago
In Rust, you can write: let x = 5i32; Sadly it's nowhere near as elegant for string literals.
- littlestymaar 6y ago
  > Sadly it's nowhere near as elegant for string literals. What do you mean? For string literals you just do let foo= "bar"; and that's it. BTW, in Rust you can omit most variable type annotations since the compiler is able to infer them. You have to give type annotations to functions though.
  - nyanpasu64 6y ago
    I meant turning string literals into heap-allocated strings.
    - littlestymaar 6y ago
      Ah yes, in this case it's indeed a bit more verbose: let foo= "bar".to_string(); It's on purpose though, because Rust likes to make heap allocations explicit, and I find it fine to be honest, but you mileage may vary.
      - nyanpasu64 6y ago
        https://users.rust-lang.org/t/to-string-vs-to-owned-for-string-literals/1441 https://users.rust-lang.org/t/to-string-vs-to-owned-for-stri... > I’m more fond of using .into(). It requires adding type hints in some cases, but for most cases it is shorter than the alternatives. Especially when passing a string literal to a function that requires String. > Now that specialization for str::to_string() has landed, we can safely say that to_string() has the same performance as to_owned(), and thus to_string() should be used since it’s more clear > I now strongly prefer to_owned() for string literals over either of to_string() or into(). yay language complexity