5 ms·

That's a reasonable position, but the popularity of languages without any type declarations at all suggests that there are many people who don't mind. (python,

That's a reasonable position, but the popularity of languages without any type declarations at all suggests that there are many people who don't mind. (python, ruby, etc.)

JoeAltmaier 12y ago
And 'auto' isn't the same as no type declaration. Auto still enforces type consistency, so its not that foreign to existing C++ expectations.
- ufo 12y ago
  Having the type be inferred is precisely what omitting a type declaration does in a static language. From the point of view of a pedantic type systems theorist, Python is like having a static language where every variable has the the same type, "Object". Anyway, they are talking about documentation. Many people think that having to peek inside a function to know what it returns is worse than having a compiler-checked type declaration. In fact, in most languages with type inference there is still a strong convention to write full signatures for all top level functions, as a form of documentation (return type inference is left for lambdas)
  - mreiland 12y ago
    I suspect that over time the C++ community will settle on a set of conventions around the use of auto in this context. Much like how passing in a mutable reference is considered a no-no and you're expected to instead pass in a mutable pointer so it's obvious to the caller that you can change the value via the parameter list.
    - femngi 12y ago
      That's not a C++ community convention, it's just another bone headed part of the Google C++ coding standards. It's stupid because now everything is potentially nullable and every single function will start with: if (!arg1 || !arg2 || !arg3 ...) { what_I_should_do_here_isnt_really_clear();
      - gtremper 12y ago
        I'm not a fan of the "pointer means mutable" idiom either. I feel you should only use a raw pointer type instead of a reference if you want nullptr to be a meaningful value. Value semantics are great.
        mreiland 12y ago
        I'm not a fan of idealism for the sake of idealism. It's practical to be able to tell at the callsite that the parameter can be changed by the function/method.
      - mreiland 12y ago
        It's been a C++ convention to use pointers for parameters that are meant to be changed for a long time. func_call(&var1); is most definitely a C++ convention bud, and it has nothing to do with google.
- crusso 12y ago
  Exactly. auto ensures consistency, but it eliminates the need to officially declare intent - which was a key part of type safety. Not only did you need to use the type correctly, but you needed to declare the desire to use a specific type from the get-go.
- deleted 12y ago
  [deleted]

That's a reasonable position, but the popularity of languages without any type declarations at all suggests that there are many people who don't mind. (python, ruby, etc.)

JoeAltmaier 12y ago

And 'auto' isn't the same as no type declaration. Auto still enforces type consistency, so its not that foreign to existing C++ expectations.

ufo 12y ago
Having the type be inferred is precisely what omitting a type declaration does in a static language. From the point of view of a pedantic type systems theorist, Python is like having a static language where every variable has the the same type, "Object". Anyway, they are talking about documentation. Many people think that having to peek inside a function to know what it returns is worse than having a compiler-checked type declaration. In fact, in most languages with type inference there is still a strong convention to write full signatures for all top level functions, as a form of documentation (return type inference is left for lambdas)
- mreiland 12y ago
  I suspect that over time the C++ community will settle on a set of conventions around the use of auto in this context. Much like how passing in a mutable reference is considered a no-no and you're expected to instead pass in a mutable pointer so it's obvious to the caller that you can change the value via the parameter list.
  - femngi 12y ago
    That's not a C++ community convention, it's just another bone headed part of the Google C++ coding standards. It's stupid because now everything is potentially nullable and every single function will start with: if (!arg1 || !arg2 || !arg3 ...) { what_I_should_do_here_isnt_really_clear();
    - gtremper 12y ago
      I'm not a fan of the "pointer means mutable" idiom either. I feel you should only use a raw pointer type instead of a reference if you want nullptr to be a meaningful value. Value semantics are great.
      - mreiland 12y ago
        I'm not a fan of idealism for the sake of idealism. It's practical to be able to tell at the callsite that the parameter can be changed by the function/method.
    - mreiland 12y ago
      It's been a C++ convention to use pointers for parameters that are meant to be changed for a long time. func_call(&var1); is most definitely a C++ convention bud, and it has nothing to do with google.
crusso 12y ago
Exactly. auto ensures consistency, but it eliminates the need to officially declare intent - which was a key part of type safety. Not only did you need to use the type correctly, but you needed to declare the desire to use a specific type from the get-go.
deleted 12y ago
[deleted]