Struct versus Class Default Access When Exposing Types Across a Library Boundary

The goal is to determine whether a library's public header should use struct or class when declaring a type that callers are expected to treat as opaque, given that the default member and base‑class access differ between the two keywords.

When a struct is chosen for brevity, its members and base classes become public by default, which can unintentionally expose implementation details and affect ABI compatibility if the type is later extended with non-public data or functions. The uncertainty lies in predicting how future changes to the type will impact existing binaries and whether callers might inadvertently depend on those now-public members.

What are the risks of relying on struct's default public access for a type intended to be opaque? How should library designers decide between struct and class to preserve encapsulation and ABI stability?