Hacker News Reader

Comment by dangerlibrary | Hacker News Reader

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.)

View on HN

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

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)

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.

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();

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.

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.

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.

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.

Reply on news.ycombinator.com