`send()` flags enum argument should have a default

[jagerman]

PR #317 added scoped enums for flags, which is great, but it also added some unpleasantness in the API that:

sock.send(some_message);

now results in a deprecatation warning, requiring a bunch of code changes to:

sock.send(some_message, zmq::send_flags::none);

which is needlessly verbose.

It looks like this was introduced because otherwise there would be an ambiguous overload with the

send(message_t &, int flags_ = 0)

(and similar rvalue reference) overloads.

I'd like to suggest that those deprecated int flags_ = 0 methods be replaced with non-defaulted values:

send(message_t &, int flags_)

and the default be added on the scoped enum version instead:

send(message_t &, send_flags flags = send_flags::none)

which seems way more useful and doesn't seem like it would break any existing code, but would un-deprecate the very common sock.send(msg) call.

I'm happy to submit a PR to implement this first, but wanted to discuss here in case there is reason to oppose allowing a "no flags" default for send/recv.

[jagerman]

I should also point out that some versions of send() do have a no-flags default, so it seems weird that the common version taking a message_t does not:

detail::send_result_t send(const_buffer buf, send_flags flags = send_flags::none)

[gummif]

Thanks for pointing that out, that was indeed the intended behaviour originally. But since the return value of the new variants is optional<size_t> that would be a breaking change.

I have been pondering if that issue could be solved with an opt in flag like ZMQ_NO_DEPRECATED to disable deprecated code, which would allow the new send function to have a default value.

[sigiesec]

I have been pondering if that issue could be solved with an opt in flag like ZMQ_NO_DEPRECATED to disable deprecated code, which would allow the new send function to have a default value.

Hm. This might add additional confusion, since the signature of the non-deprecated function would be different then with and without defining ZMQ_NO_DEPRECATED, and not simply removing deprecated functions. Maybe we can just find a good time to publish a new major version that drops all or some of the deprecated functions. We should seek feedback for doing so on the zeromq-dev list.