add in-class initializers to primitive fields

[Joseph Borodach (JosephBorodach)]

Add in-class initializers to primitive fields across all remaining POD types in the SDK

Why

Followup to #687, which fixed Camera::properties only. Same footgun exists in every other POD carried over gRPC

[Andrew C. Morrow (acmorrow)]

I want to think about this one for a bit

[Andrew C. Morrow (acmorrow)]

Joseph Borodach (@JosephBorodach) - I spent some time musing about this. As an old-school high-performance C++ type, my initial reaction was that I didn't like the idea. Basically, by giving these types non-static data-member initializers, they are no longer trivial types. So, for instance, it is no longer free to allocate an array of them, because now each one needs initialization. From there, I'd have argued that users who write, for instance, struct pose instead of struct pose{} have written a bug. My preference would have been that we relied on tooling to catch the bugs, rather than penalizing all uses of these types.

However, practical considerations I think rule the day the other way, in favor of your change.

• The only tooling that actually catches this is MSAN, which requires instrumentation all the way through the C++ runtime library, which is impractical. Static analysis tools and -W[maybe-]uninitialized either do not reliably catch misuse, are plagued with false positives, or both.
• While C++ SDK authors can probably be held to the standard of knowing the difference between pose and pose{} and when to use each, it is probably not reasonable to hold module authors to that level of rigor. Since the types you are changing here are the user vocabulary types, and not the wire types, they should have good user facing ergonomics.
• Future versions of the standard lean toward what you are doing here, along the lines of -ftrivial-auto-var-init=zero and future C++ standards evolution (see P2795).

So, having thought about it and done some research, I'm somewhat reluctantly in favor. I will take a pass through the changes themselves to see if any of them require more thought.

[Joseph Borodach (JosephBorodach)]

Thanks for taking the time to think it through Andrew C. Morrow (@acmorrow) - the tradeoff you're weighing is the right one, and I appreciate you landing on the ergonomics side despite the triviality cost.

[Andrew C. Morrow (acmorrow)]

LGTM, but I'd like lia (@lia-viam) to take a second look in case any of the defaults have semantics I'm not aware of.

[viam-overwatch]

Hey Joseph Borodach (@JosephBorodach) — this PR has been approved and CI has been green for 3+ business days. Ready to merge?

Auto-comment from overwatch. Will not re-nudge for 7 days.

[lia (lia-viam)]

can this not just be = {} ?

[Joseph Borodach (JosephBorodach)]

Good catch and it's more consistent with the other defaults in this PR. Updating