In larger codebases with many developers, attention to the API is required in order to be able to maintain code without breaking clients.
The main downside of Badge<T> is that it comes with a performance penalty and ABI change for something that should be statically deducible (empty struct is one byte in C++).
The example also shows a call to a different translation unit. There's no code for passing the empty struct. There's also none for handling it, as you can see from the assembly output.
The one byte rule does nothing here, because its value is undefined and its address not observable.
edit: if you find a case where an empty struct parameter causes code to be emitted, let's consider filing bugs.
Oops, I did miss that, but this seems to be compiler or calling convention specific. x86_64 gcc 9.1, linked, shows no difference. However arm64 gcc 8.2 and x86-64 clang show a difference.
Don't you have to have pretty high performance needs for this class to make a performance difference? Unless it's called multiple thousand times per second I don't see it making much of a difference.
You can make register_device() an inline function that just calls a do_register_device() private function without the badge. That way you don't have to pay for the empty class.
I'm not sure I follow... The motivation for Badge is to have methods on VFS that only Device can call, without exposing VFS's internals to Device. Without Badge, what prevents non-Device functions from calling register_device()?
I guess the inline function would require a Badge and the private member function would not. So an inline constructed but never used Badge is even more likely to be completely optimized away
The main downside of Badge<T> is that it comes with a performance penalty and ABI change for something that should be statically deducible (empty struct is one byte in C++).