On 9/10/2018 03:22, Peter Dimov wrote:
I admit I haven't given this much thought because the assumption was that having categories that do not override the new `message` would be just a temporary state of affairs. The desire to not allocate comes at least as much from people writing categories as from those using them; the objection was that even when your category _could_ return literals it had no way to do so.
The default implementation comes into play in a scenario in which the client has "upgraded" to the new overload, but the (third party - system and generic are already up to date) category hasn't, and I've decided to preserve the message as much as possible rather than to enforce the "no allocation" property at the expense of losing the message. Maybe this is not the correct choice, I'm not sure. But again, this scenario should eventually never occur as third-party categories are updated.
I'm not sure either (so I hope that others chime in with their thoughts -- especially Niall, since he's worked with many of the people who I imagine would have strong opinions one way or the other). A related hesitation that I have is that while the caller can ask if there is a literal message (by passing nullptr,0) they can't otherwise ask for a possibly-dynamic-but-non-allocating (eg. snprintf) message. So if this fallback to the allocating-message() exists, it means that the caller either has to ask only for literal messages (thus failing to get snprintf messages) or they have to rely on out-of-band knowledge that the specific category of the error happens to support non-allocating messages, or risk hitting an undesirable allocating path. On the other hand, people who care about that sort of thing are perhaps more likely to use a custom STL or carefully chosen libraries known to not generate such errors, so perhaps this is not worth worrying about.