Sorry, I wasn't really clear before. The presence or not of the handler parameter is the difference in the function *signatures*. How the function actually behaves is quite different (a synchronous call blocks the calling thread, an asynchronous call never blocks). It is not the handler parameter that determines whether the operation is synchronous or asynchronous; the handler is just the function that is called when the asynchronous operation completes.
Actually, I understood how you intended it to work, but I had been trying to convince myself that it's truly better for the asynchronous calls to have a different signature than the synchronous call, and I wasn't able to convince myself. So I was hoping that you'd do it. ;-) The devil's advocate position remains: synchronous operation is merely the particular case where the handling policy prevents the function from returning control to the caller until the operation has completed; no unique function signature is warranted.
What do you think of my proposal in my email earlier today where basically I use "read" and "write" for the operations that are in the *Stream concepts (and so could equally apply to pipes, files and so on), but retain "send" and "receive" (and "send_to" and "receive_from") for operations that are specific to sockets?
It would be better if use of "read" and "write" were ubiquitious, but if there's an overloading clash, I guess you have to do what you have to do. Dave