Open jwmelto opened 1 year ago
Yes this is an unfortunate result of the API change. Warnings are better than breaking the code (who knows what the users do with the result of the function).
A possible solution would be to add a macro CPPZMQ_NO_DEPRECATED where we (maybe) break things but the API is cleaner with better defaults. Would that be acceptable in your case? Or just not deprecate that particular function?
when most of the legacy API calls were deprecated, "valid" (??) code suddenly raises deprecation warnings.
In particular,
This results from
and
(note the inconsistency between buffer and message_t)
But if the new API had been given a reasonable default, there would be no need to touch legacy code:
Of course, there is an API issue where legacy
send
could return either abool
or a number of bytes (that's bitten me before), and the new API returns astd::optional<size_t>
but for that kind of breaking change, it probably would have been better to not overload the function name.I realize this change is now quite old (324b11f239511), but maintainers of legacy code are now faced with non-intuitive modifications, when more careful migration planning might have addressed it.
Note that the conversion of
std::optional<T>
tobool
probably gives the desired results (I haven't thought it completely through), so it's probable that the new API is drop-in replacable. The main point should be to minimize breaking changes. Deprecating "normal" code seems to be contrary to that aim.