Hcfyk

Reading this blog post and its comments, I have noticed that it gives as an example the possibility of marking specific function parameters as deprecated, as in (exaple taken from the post):

// Deprecate a function parameter

int triple([[deprecated]] int x);

Now I was wondering, what is a good use case for such a feature? No one in the comments of that post or anywhere else I have searched seem to have a clue.

EDIT:

To see it in action, there is a compilable example on goldbolt

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.

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]].

Imagine a library that is implemented, used and maintained for many years. This library is used in multiple projects.

If you would simply remove the parameter, all the projects would have to immediately adapt the source code to be able to compile again, after they upgraded to the new library version.

If a default value is added to the parameter, but the parameter not used anymore, the projects would still compile without any change, but nobody would note that something has changed at all, and maybe some behaviour/feature that was controlled by this parameter does not work anymore.

So, by marking the parameter as deprecated the projects can compile without a change, but they get a warning that something has changed and that they should change their source code, because sooner or later this parameter will disappear.