I started my career doing C++ at Google, so for those engineering habits that I haven't thought through or otherwise have a strong opinion about, my defaults are in line with the GSG. But avoiding non-const references is something that I find myself in pretty strong agreement with, as part of a coding style that makes function signatures for complex logic as simple and comprehensible as possible. I'd be interested in hearing the perspective behind your reasoning otherwise. Is it mainly for the ability to signal non-nullability in the signature?
> Is it mainly for the ability to signal non-nullability in the signature?
Can't answer for the parent, but for me yes it's exactly that.
When I'm calling a function I'm going to look up the prototype anyways so I don't really care whether it's taking a reference or a pointer.
When I'm implementing the function, I want to make sure that all my callers never pass me a nullptr. Because of the styleguide I'm forced to put a "DCHECK(ptr);" and add a comment in the prototype saying "|ptr| must not be null".
I started my career doing C++ at Google, so for those engineering habits that I haven't thought through or otherwise have a strong opinion about, my defaults are in line with the GSG. But avoiding non-const references is something that I find myself in pretty strong agreement with, as part of a coding style that makes function signatures for complex logic as simple and comprehensible as possible. I'd be interested in hearing the perspective behind your reasoning otherwise. Is it mainly for the ability to signal non-nullability in the signature?