> I don't remember the last time where I passed an argument to a C++ function and actually had to wonder if the argument was modified or not. Like, what if they are being modified if that's the called function has to do anyways

That's not what I was complaining about. I am saying that, as a reader of the code, it is easier to reason about what happens in this situation:

    foo (&bar);
    ...
    if (bar) { do something }

than in this situation:

    foo (bar);
    ...
    if (bar) { do something }

> mynet_accept({ .fd = the_socket, .port = 4556 });

That's not functionally the same as the example I posted. In any case, I was using the example to point out that using pointers provides a more flexible API contract.

When using pointers, the contract can state that any parameters that are NULL are ignored, whether they are out parameters or not.

> Like, what if they are being modified if that's the called function has to do anyways ?

The idea is that you have some code like this:

  x = some_func();
  do_something(x);
  if x == 0 {
    do_something_else();
  }

You're trying to track down why do_something_else() wasn't called, let's say. Do you have to look at the definition of do_something()? If your coding standards say "no non-const references", then no. If do_something() was modifying x, it would have looked differently, so you can ignore it.

To stay on topic, if x was declared const, you wouldn't have to guess. The compiler would tell you.

> To stay on topic, if x was declared const, you wouldn't have to guess. The compiler would tell you.

Frequently it can't be declared constant, because it is being changed in that scope as it runs.

This was a discussion about passing out (or inout) parameters as `T&` vs `T*`. By definition, these parameters can't be const, so const is irrelevant to this thread.

Good point.

> You're trying to track down why do_something_else() wasn't called, let's say

Then I put a breakpoint at that line and hit f5 and don't try to guess what may or may not happen because in the end that's the only way to know what actually happens

> Then I put a breakpoint at that line and hit f5 and don't try to guess what may or may not happen because in the end that's the only way to know what actually happens

There's no need to guess if the parameter is passed by value only. When pointers are used visual inspection alone is enough to ensure that the reader knows what he value of the argument is after the callee returns.

I said that it's easier to read when pointers are used, and you propose stepping through the code as an alternative. Surely you see my point now?

You can't always reproduce a bug. Also, do you Step Over do_something(x) or Step Into? You definitely step into if it's do_something(&x).

> $ rg "const_cast" -g '*.cpp' | wc -l

not really a fair count though, since those casts may also be adding const