Mark as deprecated function parameters in C++14

Say you had a function like this:

void* allocate(std::size_t sz, void* hint = nullptr) {
    // if you give `hint` it *might* be more efficient
}

And then you decided that it is no longer worth the effort to do stuff based on hint. So you would do this:

void* allocate(std::size_t sz, [[deprecated]] void* hint = nullptr) {
    // `hint` is ignored. The compiler warns me if I use it in the
    // function body accidentally, and people reading the function
    // signature can see that it is probably going to be ignored.
}

This allows the library to keep the same signature/ABI (So you don't need to recompile stuff that uses it and legacy code can still keep using it without doing any harm), and also prevents it from accidentally being used again when changing the function.

But this is mostly for developers of the function, not the users of the function, in the future so they know why a seemingly "useless" parameter is there.

I would also think that this would disable the "unused parameter" warning with the -Werror=unused-parameter flag in gcc/clang, but it doesn't. Using (void) deprecated_parameter also issues a warning about using a deprecated parameter, so this seems like a bug. If it did disable the unused param warning, that would be another use case for [[deprecated]].


The rule is that the attribute is valid on, amongst other things, variable declarations (broadly). It's not specifically permitted for such declarations found in function arguments.

The original proposal, N3394, doesn't mention such a use case, either, and neither does the documentation for the original feature in GCC (which regardless accepts the equivalent usage) or in VS (I didn't check Clang).

As such, I think it's an "accident" that this is permitted, not something that anyone really had in mind as being useful.

Could it be useful to document deprecated defaulted arguments, as Artyer explores? Yes, potentially, and vaguely. But as Artyer also found, mainstream compilers don't actually react to this usage in a helpful manner.

So, at the present time, it's not useful, and the language feature wasn't particularly designed to be useful in this case.