Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

What's the rationale for auto return type deduction and -> declaration at the same time?


This is a stylistic difference, as there are some places where the leading return type is invalid, but a trailing return type using the -> is valid. For example, an immediately invoked lambda expression in which some of the returned values require type conversions.

For this reason, some prefer a “auto almost everywhere” style, in which you preferentially use trailing return types.


Not OP but I prefer trailing return type syntax if I were designing a language from scratch... I sometimes wish C++11 would have added the `func` keyword as an alias for `auto` in function declarations.


With macros, anything is possible.


herb has a talk where he describes its rationale.

it is known as sticky syntax in relation to auto (but specifically when the type on the rhs is explicitly declared and not abstracted away with a function signature)

it removes narrowing, inference, while keeping benefits of auto related to inits etc.

it's a way of telling the compiler we want this type moving forward and adheres to the convention of right-to-left reading w.r.t. resource allocation semantics C++ programmers are often accustomed to.


Trailing return type declaration (-> type) was needed to declare the return tyoe of a lambda — no other way to get that info into the grammar.

Then once that was opened some folks felt it would be better to write their regular code that way too.


Consistency. The rationale is: "always use auto as the return type, and add a postfix type if inference can't do the job for a reason or another."


> add a postfix type if inference can't do the job for a reason or another

Ehh... not putting a return type in at all is a bridge to far IMO. Be friendly to the casual reader of the code, and help them understand what the function returns. (Yes I know IDE's can do this for you, but not everyone uses an IDE, and not everyone is reading the code in the context of an IDE... for instance code review, etc.)


Ehh… not using an IDE is a bridge too far IMO. Be friendly to the casual writer of the code and help them express themselves without having to repeat the obvious. (Yes, I know, we write less time than read, but maybe that is what is actually wrong with the tools we use?)

Wrote this for myself, I’m a vim user :)


Mandating or expecting tools for others is a problem. Many code reviews are done in web settings, and that was an example you ignored fromt he person you responded.

And you ignored any value that actually specifying the type can have.

You also ignored the age old wisdom that code is written once and read many times.


Why are you attacking me? I just put some motivation for myself and maybe someone else to switch to an IDE. Is this mandating tools thing a problem where you are working? How did that affect you?


Why do you feel attacked? You aren't your ideas, and in this case you had a bad idea.

You said that people not having an IDE was "bridge too far" meaning that people should always have them. We already had examples of where that simply isn't true so your idea was demonstrated as wrong. Own it get a better idea and move on. I certainly had until I went through my past comments looking for childiah arguments and found one.


Most of the time the compiler can deduce it so why bother writing the return type?


So every reader should desuce it too?

Sometimes it deduces "wrong". (As in not the type the coder was expecting, so really the dev was wrong and missed a possible bug)


Those cases are the ones for which the explicit return type was intended. And if the deduced type is counterintuitive you could also use the explicit return type (or a comment: there are good arguments for either choice).

But if your argument is "this makes the reader do extra work" then that's an argument against all uses of `auto`. Now I do consider reader clarity a legitimate (and important) design criterion (and argument in code review), but I don't think it is reasonable in this case.

In fact I consider type deduction with auto to be an important element of readability: it tells the reader not to worry about the type and focus on the logic. Then the cases when a type is explicitly specified it tells the reader that it's worth paying attention.


Ideally, functions should be clear at the call site without a reader having to jump to the declaration to understand what's going on, and you don't get the return type there in the first place.


This looks like the worse of both worlds to me -- more typing, less readability and you'd still need to manually change the return type, if need be.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: