5 ms·

> You have to repeat the type information, a lot. Nope you don't, that's what typedefs are for. They're underrated for sure though. People don't use them nearl

> You have to repeat the type information, a lot. Nope you don't, that's what typedefs are for. They're underrated for sure though. People don't use them nearly as much as they should. They're incredibly valuable for avoiding precisely this problem.

nicoburns 6y ago
That doesn't stop you having to type e.g. String foo = "bar"; String baz = foo; The `String`s can be completely avoided in languages with type inference because it's obvious that a string literal is a string.
- oblio 6y ago
  Java now has (limited) type inference, bar. As does C++, auto. They're limited but they remove a lot of tedium.
- mehrdadn 6y ago
  I thought the complaint was about the logic duplication, not the extra keystrokes. If you want type inference you already have auto. If you want to minimize your keystrokes, you're using the wrong language to begin with, whether there's type inference or not. C++ is designed for writing software robustly, not quickly. (<-- This is not a trivial or obvious statement btw. It took me several years to grasp this. And I viewed C++ from an entirely different perspective when it finally sunk in for me that I would appreciate C++ much more if I decided to make minimizing keystrokes a non-goal.)
  - secondcoming 6y ago
    > If you want type inference you already have auto or auto&&. Did you really intend to make a copy?
    - mehrdadn 6y ago
      You probably did intend it to be a copy if you're binding it to a variable and need it to be non-const (like in the example)!
      - secondcoming 6y ago
        Ah, but you knew that because that's how the code was written! If it was instead String foo = "bar"; auto baz = foo; you don't know for sure. But the code compiles so it obviously ok!
        mehrdadn 6y ago
        No, I'm saying even in that case you know it was intended to be a copy. If you wanted that to be a reference then you'd either (a) just do the obvious thing which is to just use the original variable name instead of creating a new variable out of the blue for no reason, (b) leave a comment explaining why you're not doing the aforementioned obvious thing, or (c) use a self-explanatory variable name to provide the explanation instead of a comment.
- UweSchmidt 6y ago
  Is it really that painful to write "String" each time? You spend at least a fraction of a second anyway to verify that you're writing the right thing, to reconsider if you should use an object or constant or refactor the function to work with a Boolean instead of a naked string; why is writing out the type such a big deal everytime this topic comes up? I remember my first attempts at programming and being annoyed that I can't add a string and an int; ever since that little bit of housekeeping of using types made sense to me and I can clearly see how it eliminates entire classes of errors.
  - silluk 6y ago
    To me it's not the trivial cases like this that make type inference useful. It's when you get longer types like `Arc<Mutex<HashMap<String, String>>>`. Granted, that could be solved with a `type` declaration (or `typedef` in C++) but it's still convenient to be able to say: `let mut x = Arc::new(Mutex::new(HashMap::new()));` and let the compiler figure out the rest based on usage.
  - wtetzner 6y ago
    > Is it really that painful to write "String" each time? I find it more painful to read code that has too many type annotations. I also find it painful to read code that has too few, so I'd argue there's a bit of an art to it. But languages that have type inference but allow type annotations at least allow you to try to hit that balance.
  - leshow 6y ago
    > I remember my first attempts at programming and being annoyed that I can't add a string and an int; ever since that little bit of housekeeping of using types made sense to me and I can clearly see how it eliminates entire classes of errors. Type inference doesn't make these errors go away. And about your other point, it's unfair to look at just a simple case of writing "string" or not as the only thing inference provides. Although I'd argue that leaving out types where possible helps readability-- it's really the more elaborate cases or intermediate steps during a longer transformation that inference helps with. Not to mention the fact that inference in closures is also really nice.
- secondcoming 6y ago
  And it's my experience that that is only a benefit to the person who wrote the code, and only for a short time. Generally, I prefer being able to read a line of code and understanding exactly what it does. If I need an IDE and have to repeatedly try to find the definition of something then, in my opinion, that's wasting my time. C++'s 'auto' is really useful but it's over-used IMO. I think that there's a belief that if you're not using 'auto' everywhere then you're not writing 'modern' C++. Just becuase your code compiles doesn't necessarily mean it's correct.
  - mehrdadn 6y ago
    +1 for auto being overused. I always felt I was shouting into the void (hah) by saying the same thing... it's nice to see someone else agrees.
  - corty 6y ago
    Code that specifies types instead of using auto is, barring compiler bugs, usually less correct. The compiler knows better than you what the type really is.
  - nicoburns 6y ago
    I find that types can reduce readability as well as enhance it. They add noise and make it harder to concentrate on the variable names which are often much more important than the types which are often (but certainly not always) obvious from context.
    - secondcoming 6y ago
      Interesting point. I'd never have believed it myself, but find myself using acronyms instead of variable names when the type allows it. void foo(MyType mt, const MyOtherType& mot); It's the variable names that are the noise, types are everything. And no, it's not Hungarian notation either in case anyone suggests it! However, it maybe doesn't work that well with things like class member names. YMMV
      - nicoburns 6y ago
msla 6y ago
Shifting topics a bit, typedefs don't allow me to write generic code. Templates do, but templates bring in their own problems, in addition to not being expressive in the right ways: I can have an array of T, but I can't specify that T is Numeric? The fact C++ doesn't have Numeric but instead has int and long and unsigned and long long and float and double all off on their own is another problem: The compiler knows enough about them to have complex promotion rules but doesn't know enough to allow me to refer to all of them under one name in my code.
- mehrdadn 6y ago
  You're asking for the impossible. What you want is precisely what templates are, but you also want them to not be "templates" for... some bizarre reason. > I can have an array of T, but I can't specify that T is Numeric? Sure you can. If you have C++20 concepts: template<class T> concept Numeric = std::integral<T> || std::floating_point<T>; template<Numeric T> T twice(T x) { return x + x; } Or if you're on a C++11 compiler: template<class T> typename std::enable_if< std::is_arithmetic<T>::value, T>::type twice(T x) { return x + x; }
  - jcelerier 6y ago
    the C++ 20 version can be simplified a bit to: Numeric auto twice(Numeric auto x) { return x + x; }
    - mehrdadn 6y ago
      Probably not a good idea since the caller won't know what the return type is at that point, and the return type would become dependent on the implementation, which breaks function abstraction. And imagine what would happen when you get a few more 'auto' variables in the return expression. Suddenly your return type will depend on the implementation of your callees. And the code can then quickly become impossible to understand. auto is overused.
      - jcelerier 6y ago

nicoburns 6y ago

That doesn't stop you having to type e.g. String foo = "bar"; String baz = foo; The `String`s can be completely avoided in languages with type inference because it's obvious that a string literal is a string.

oblio 6y ago
Java now has (limited) type inference, bar. As does C++, auto. They're limited but they remove a lot of tedium.
mehrdadn 6y ago
I thought the complaint was about the logic duplication, not the extra keystrokes. If you want type inference you already have auto. If you want to minimize your keystrokes, you're using the wrong language to begin with, whether there's type inference or not. C++ is designed for writing software robustly, not quickly. (<-- This is not a trivial or obvious statement btw. It took me several years to grasp this. And I viewed C++ from an entirely different perspective when it finally sunk in for me that I would appreciate C++ much more if I decided to make minimizing keystrokes a non-goal.)
- secondcoming 6y ago
  > If you want type inference you already have auto or auto&&. Did you really intend to make a copy?
  - mehrdadn 6y ago
    You probably did intend it to be a copy if you're binding it to a variable and need it to be non-const (like in the example)!
    - secondcoming 6y ago
      Ah, but you knew that because that's how the code was written! If it was instead String foo = "bar"; auto baz = foo; you don't know for sure. But the code compiles so it obviously ok!
      - mehrdadn 6y ago
        No, I'm saying even in that case you know it was intended to be a copy. If you wanted that to be a reference then you'd either (a) just do the obvious thing which is to just use the original variable name instead of creating a new variable out of the blue for no reason, (b) leave a comment explaining why you're not doing the aforementioned obvious thing, or (c) use a self-explanatory variable name to provide the explanation instead of a comment.
UweSchmidt 6y ago
Is it really that painful to write "String" each time? You spend at least a fraction of a second anyway to verify that you're writing the right thing, to reconsider if you should use an object or constant or refactor the function to work with a Boolean instead of a naked string; why is writing out the type such a big deal everytime this topic comes up? I remember my first attempts at programming and being annoyed that I can't add a string and an int; ever since that little bit of housekeeping of using types made sense to me and I can clearly see how it eliminates entire classes of errors.
- silluk 6y ago
  To me it's not the trivial cases like this that make type inference useful. It's when you get longer types like `Arc<Mutex<HashMap<String, String>>>`. Granted, that could be solved with a `type` declaration (or `typedef` in C++) but it's still convenient to be able to say: `let mut x = Arc::new(Mutex::new(HashMap::new()));` and let the compiler figure out the rest based on usage.
- wtetzner 6y ago
  > Is it really that painful to write "String" each time? I find it more painful to read code that has too many type annotations. I also find it painful to read code that has too few, so I'd argue there's a bit of an art to it. But languages that have type inference but allow type annotations at least allow you to try to hit that balance.
- leshow 6y ago
  > I remember my first attempts at programming and being annoyed that I can't add a string and an int; ever since that little bit of housekeeping of using types made sense to me and I can clearly see how it eliminates entire classes of errors. Type inference doesn't make these errors go away. And about your other point, it's unfair to look at just a simple case of writing "string" or not as the only thing inference provides. Although I'd argue that leaving out types where possible helps readability-- it's really the more elaborate cases or intermediate steps during a longer transformation that inference helps with. Not to mention the fact that inference in closures is also really nice.
secondcoming 6y ago
And it's my experience that that is only a benefit to the person who wrote the code, and only for a short time. Generally, I prefer being able to read a line of code and understanding exactly what it does. If I need an IDE and have to repeatedly try to find the definition of something then, in my opinion, that's wasting my time. C++'s 'auto' is really useful but it's over-used IMO. I think that there's a belief that if you're not using 'auto' everywhere then you're not writing 'modern' C++. Just becuase your code compiles doesn't necessarily mean it's correct.
- mehrdadn 6y ago
  +1 for auto being overused. I always felt I was shouting into the void (hah) by saying the same thing... it's nice to see someone else agrees.
- corty 6y ago
  Code that specifies types instead of using auto is, barring compiler bugs, usually less correct. The compiler knows better than you what the type really is.
- nicoburns 6y ago
  I find that types can reduce readability as well as enhance it. They add noise and make it harder to concentrate on the variable names which are often much more important than the types which are often (but certainly not always) obvious from context.
  - secondcoming 6y ago
    Interesting point. I'd never have believed it myself, but find myself using acronyms instead of variable names when the type allows it. void foo(MyType mt, const MyOtherType& mot); It's the variable names that are the noise, types are everything. And no, it's not Hungarian notation either in case anyone suggests it! However, it maybe doesn't work that well with things like class member names. YMMV
    - nicoburns 6y ago

msla 6y ago

Shifting topics a bit, typedefs don't allow me to write generic code. Templates do, but templates bring in their own problems, in addition to not being expressive in the right ways: I can have an array of T, but I can't specify that T is Numeric? The fact C++ doesn't have Numeric but instead has int and long and unsigned and long long and float and double all off on their own is another problem: The compiler knows enough about them to have complex promotion rules but doesn't know enough to allow me to refer to all of them under one name in my code.

mehrdadn 6y ago
You're asking for the impossible. What you want is precisely what templates are, but you also want them to not be "templates" for... some bizarre reason. > I can have an array of T, but I can't specify that T is Numeric? Sure you can. If you have C++20 concepts: template<class T> concept Numeric = std::integral<T> || std::floating_point<T>; template<Numeric T> T twice(T x) { return x + x; } Or if you're on a C++11 compiler: template<class T> typename std::enable_if< std::is_arithmetic<T>::value, T>::type twice(T x) { return x + x; }
- jcelerier 6y ago
  the C++ 20 version can be simplified a bit to: Numeric auto twice(Numeric auto x) { return x + x; }
  - mehrdadn 6y ago
    Probably not a good idea since the caller won't know what the return type is at that point, and the return type would become dependent on the implementation, which breaks function abstraction. And imagine what would happen when you get a few more 'auto' variables in the return expression. Suddenly your return type will depend on the implementation of your callees. And the code can then quickly become impossible to understand. auto is overused.
    - jcelerier 6y ago