12

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

bracco23
  • 2,181
  • 10
  • 28
  • Hm. I was thinking default arguments, but gcc doesn't warn on either statement in `void f([[deprecated]] int n = 0); void g() { f(); f(2); }`. It only warns within the function body. – aschepler May 28 '19 at 10:56
  • Using gcc trunk, as you can see [on goldbolt](https://godbolt.org/z/ZoG1Be), the warning is issued when the parameter is used inside the function, not at call, that's why it is puzzling. – bracco23 May 28 '19 at 11:00
  • 1
    Why do you assume that there is a use case? Maybe it's possible just because there was not an exception made to disallow it. – eerorika May 28 '19 at 11:04
  • 1
    @eerorika I am not assuming there is a use case. It is entirely possible this feature just happened to be available without any planning for it and to not be harmful to leave it as it is, yet I am curious to know if there is actually a use case. – bracco23 May 28 '19 at 12:04

3 Answers3

10

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

Artyer
  • 31,034
  • 3
  • 47
  • 75
  • 1
    But neither clang++ nor g++ actually warn about any calls to the function, whether or not they give an argument for `hint`. – aschepler May 28 '19 at 11:18
  • @aschepler Yes, because that parameter is always passed anyways (even if it is implicitly on the callers side because of the default parameter), and it's different from the whole function being deprecated. It's more like it is deprecated inside the function body, but the caller doesn't always need to care about that. – Artyer May 28 '19 at 11:26
  • 1
    That's neat. But it's not as idiomatic as just removing the parameter name once that's been cleaned up. – StoryTeller - Unslander Monica May 28 '19 at 14:40
4

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.

Lightness Races in Orbit
  • 378,754
  • 76
  • 643
  • 1,055
  • While I can see how such a corner case might happen without being planned, I think it is unlikely it has been unnoticed for all this time. Any reference to it in some discussion after it has been introduced? – bracco23 May 28 '19 at 13:34
  • I don't think it "hasn't been noticed", I think you're just the first person to care :P After all, there are plenty of other useless pieces of code we can write, and that's up to us as individuals. In other words: why bother writing a special rule into the language to prohibit it? What would we gain from such a complication? That's really the crux of it. – Lightness Races in Orbit May 28 '19 at 13:41
0

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.

Rene
  • 2,466
  • 1
  • 12
  • 18
  • 2
    But both g++ and clang++ warn only on uses of the parameter within that function's definition, and not on any calls to the function, whether or not they provide an argument for that parameter. This is the opposite of what you describe. – aschepler May 28 '19 at 11:17