This has honestly never ever been an issue for me. 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 ? And even if it's const, the implementation can just remove the const which while not a very nice thing to do, is legal in many cases.

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

> mynet_accept(int listener_fd, char *remote_ip, uint16_t *remote_port);

For this exact case my go-to solution nowadays is

    struct connection_info { 
      int fd;
      std::string ip;
      uint16_t port;
    };  

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

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 }

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

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.

The idea is that you have some code like this:

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

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

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?

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

Almost never, in my experience. During code review, when I see this:

    foo(&bar);

When I see this:

    foo(bar);

In a place where the convention is to use pointers instead of mutable references I never have to ask the question - the code review of the implementation of `foo` would have changed the mutable reference parameter to a pointer parameter.

I read code much more often than I write it. References hurt readability.