That is entirely application specific. If you have an application, where logging is a legal requirement, you absolutely would want to terminate the application if logging is unable to succeed/continue.
For "Logging" in particular, I don't see why the API would ever return a value that should be "must use". If alternative logging mechanism is available, and the user of the library either allowed (or at least didn't decline) that alternative, then the API should simply automatically switch to the alternative mechanism and the return value should simply indicate the switch (if it is even needed at all which is debatable), but that return value would not be "must use". If the application absolutely must use logging (say it is required for legal compliance, like HIPAA) and the logging mechanism can no longer work at all, it should be a configurable parameter of the framework or a passed parameter or a different API call that chooses between: 1) return a value indicating success or failure with reason for failure (that is not "must use", though perhaps is "should use", 2) panic/abort, or 3) the function called has a "must use", but, that means it is "MUST USE", not "SHOULD USE".
I just don't see how something like a logging API (or any other I can think of for that matter) should have a "must use" that didn't actually mean "MUST USE". I also think that the notion of "should use" (which is what I believe is being modeled by the current "must use" annotation) is superfluous because, if an API defines a return value, it is implicit that you should, at the very least, use it in some fashion. If that isn't needed by the API, why return a value in the first place. Why not just return
() if there is nothing relevant for the caller to use.
I guess what I'm saying, is any value returned from a function should be implicitly treated as "should use" and if the value being returned is truly superfluous, then, the API author should correct that bug by return
() instead. If there truly is some need to have a function/API that returns values that it really doesn't matter if the caller uses them in any fashion or not (which I am very skeptical of), perhaps there should be a
#[superfluous_return_value] annotation instead to quiet the warning for unused return value that should occur normally.
In the case where the return value really MUST be used for correct usage of the API, that would be the purpose of the
#[must_use] annotation. In that case though, it would be good to have a way to specify clearly what constitutes "usage". Also, it wouldn't be a warning to not use it, but a compiler error. The kind of thing that would constitute defining clearly what is real "usage" would be one of:
- Without qualification would mean simply that the return value must not be dropped before doing something else within the scope after the value is returned AND that it would be an error to pass ownership of the value to another method or function. This would be used for things like "Scope Guards".
- A list of 1 or more inherent or trait methods one of which must be called on the return value that takes ownership of the value as "Self" (preferred) before the end of the scope. In this case, calling any other function or method that takes ownership of the value would be a compiler error. Also, with this type, the compiler would require that something is done within the scope between the return value and the calling of the method that consumes the value. This would be used to model "Relevant Types" that could not be placed in a container without the intervention and knowledge of the API author (including a Box).
An extension, perhaps, would be to provide a
#[use_guaranteed] annotation that could apply to parameters that take ownership. In the case, the function/method is making the guarantee that could be used to take ownership in case 1, but not case 2, to allow the "scope" of use to be passed/handed off. A parameter of a function annoted with
#[use_guaranteed] would have the same requirements to "use" the value as if it were returned from a function that used
#[must_use] (without further qualification). I'm not sure I can think of a useful reason to have this though.