0

Recently, I had a bug where, we changed the function from

void update_waypoint_heading(const double new_observation, waypoint)
{
   // ....
   waypoint.heading = default_heading_deg * waypoint.some_magic_number
}


// Call the function and the function will calculate new heading and mutate heading in waypoint
update_waypoint_heading(new_observation, waypoint);

to

double update_waypoint_heading(const double new_observation, waypoint)
{
   // ....
   return default_heading_deg * waypoint.some_magic_number
}

// Here the caller is supposed to be responsible for mutation
waypoint.heading = update_waypoint_heading(new_observation, waypoint);

We had a bug where we changed the function but did not change the caller. So we ended with

update_waypoint_heading(new_observation, waypoint);

Where update_waypoint_heading started to return the new heading. But it never got set to the waypoint. This was also perfectly legal for the compiler.

Is it possible to declare a parameter as mutant (like the opposite of const), where it will throw a compiler error if it does not get mutated. So that I can catch these cases at compile time

NathanOliver
  • 171,901
  • 28
  • 288
  • 402
samol
  • 18,950
  • 32
  • 88
  • 127
  • 1
    You should be able to enable a compiler warning for ignoring the return value instead: https://stackoverflow.com/questions/2870529/g-how-to-get-warning-on-ignoring-function-return-value – NathanOliver May 24 '19 at 16:28
  • @samol What is the type of the paramener waypoint? – Vlad from Moscow May 24 '19 at 16:39
  • 2
    You already broke the API so you might as well change the function to `double get_waypoint_heading(const double new_observation, const waypoint_type& waypoint);` This will catch every prior use of the now gone function. – Nikos C. May 24 '19 at 16:49

1 Answers1

4

No, and it wouldn't make much sense either.

You pass an argument into a function, and want a keyword to mandate that the calling scope then assigns the result of that function into some part of the same thing you passed as an argument?

This is very convoluted.

If a function returns a result that ought to be used, then that is documented by its return type. If it modifies its by-reference arguments, then that should also be documented. Do not switch from one to the other after you've already got code using that function!

HOWEVER! There is the nodiscard attribute which will prevent the result of calling the function from simply being, well, discarded. That would have flagged this case up, and may be what you're really looking for.

You'll need a nice C++17 compiler to use it.

I still think this is a bit leaky, though. It's not up to your function to decide what the calling scope does with its result. Just don't change function semantics! Write a new function with a new name if you need to. "Update" is no longer a good descriptive name for what it does anyway.

Lightness Races in Orbit
  • 378,754
  • 76
  • 643
  • 1,055
  • Personally, I'm okay with idempotent, side-effect free functions being marked `nodiscard`. If the function is purely a "arguments in, results out" function, then attempts to call it without using the return value are almost always errors. And it can be silenced for the rare cases you might need it (e.g. microbenchmark timing or the like) with a simple cast to void, so it's not onerous to work around. – ShadowRanger May 24 '19 at 16:55
  • Weeeeell I suppose. But I still think in this particular case simply renaming the function would have been a strong choice. – Lightness Races in Orbit May 24 '19 at 16:59