5 ms·

> you can still use the value returned by e.g. comparing it to other values and so on without needing to know the exact type. No no no no nonononono. No! Loos

> you can still use the value returned by e.g. comparing it to other values and so on without needing to know the exact type. No no no no nonononono. No! Loose typing was a mistake. I think any sober analyst of C and C++ knows that. The languages have been trying to rectify it ever since. But dynamic typing was an even bigger mistake. Perversely, it's one caused by a language not having a compiler that can type check the code, which C does. I want to actually know what my code is doing, thanks. If you want "expressive" programs that are impossible to reason about, just build the whole thing in Python or JS. (And then pull the classic move of breaking out mypy or TypeScript half way in to development, tee hee.) The only time `auto` is acceptable is when used for lambdas or things whose type is already deducable from the initializer, like `auto p = make_unique<Foo>()`.

unwind 4y ago
There is nothing "dynamic" about what I suggested. There is a real, concrete, static and compile-time known type at all times. In this case it would be long. I fail to see the huge risk you're implying by operating upon a long-typed value without repeating the type name in the code. const auto pos_auto = ftell(fp); const long pos_long = ftell(fp); I don't understand what you can do with 'pos_long' that would be dangerous doing with 'pos_auto' (again, disregarding I/O since then you typically have to know or cast).
- shrimp_emoji 3y ago
  > again, disregarding I/O since then you typically have to know or cast Thank you for answering for me!
  - astrange 3y ago
    `const long pos_long = ftell(fp);` contains a potential implicit case in the future if the return type of `ftell()` changes. That's one reason type inference is safer than not inferring. Your program doesn't include semantics you didn't actually intend to be part of its meaning. Also, I think lambdas would be annoying without it.
grumpyprole 4y ago
You are confusing dynamic types with type inference.
- shrimp_emoji 3y ago
  I'm not, although it apparently came off that way. I meant that, to a person reading the code, `auto` tells you about as much about the type you're looking at as no type at all (like in a dynamically typed language). This chatter said it better: https://news.ycombinator.com/item?id=35814337 https://news.ycombinator.com/item?id=35814337
  - grumpyprole 3y ago
    This is where tooling can help. An IDE could display the type next to all auto symbols if you want. Or allow you to query it with a keyboard shortcut. This gives the best of both worlds, rather than forcing everyone to write out the types all the time. Sometimes we simply don't care what the exact type is, e.g. if it's an object created and consumed by an API. We still want it type-checked, but we don't want to be forced to write out the type.

unwind 4y ago

There is nothing "dynamic" about what I suggested. There is a real, concrete, static and compile-time known type at all times. In this case it would be long. I fail to see the huge risk you're implying by operating upon a long-typed value without repeating the type name in the code. const auto pos_auto = ftell(fp); const long pos_long = ftell(fp); I don't understand what you can do with 'pos_long' that would be dangerous doing with 'pos_auto' (again, disregarding I/O since then you typically have to know or cast).

shrimp_emoji 3y ago
> again, disregarding I/O since then you typically have to know or cast Thank you for answering for me!
- astrange 3y ago
  `const long pos_long = ftell(fp);` contains a potential implicit case in the future if the return type of `ftell()` changes. That's one reason type inference is safer than not inferring. Your program doesn't include semantics you didn't actually intend to be part of its meaning. Also, I think lambdas would be annoying without it.

grumpyprole 4y ago

You are confusing dynamic types with type inference.

shrimp_emoji 3y ago
I'm not, although it apparently came off that way. I meant that, to a person reading the code, `auto` tells you about as much about the type you're looking at as no type at all (like in a dynamically typed language). This chatter said it better: https://news.ycombinator.com/item?id=35814337 https://news.ycombinator.com/item?id=35814337
- grumpyprole 3y ago
  This is where tooling can help. An IDE could display the type next to all auto symbols if you want. Or allow you to query it with a keyboard shortcut. This gives the best of both worlds, rather than forcing everyone to write out the types all the time. Sometimes we simply don't care what the exact type is, e.g. if it's an object created and consumed by an API. We still want it type-checked, but we don't want to be forced to write out the type.