Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Improve forwards compatibility of input API
This adds a `#[doc(hidden)]` `__Unknown(u32)` variant to the various enums to keep them extensible without requiring API breaks. We need to consider that most enums that are based on Android SDK enums may be extended across different versions of Android (i.e. effectively at runtime) or extended in new versions of `android-activity` when we pull in the latest NDK/SDK constants. In particular in the case that there is some unknown variant we at least want to be able to preserve the integer value to allow the values to be either passed back into the SDK (it doesn't always matter whether we know the semantics of a variant at compile time) or passed on to something downstream that could be independently updated to know the semantics. We don't want it to be an API break to extend these enums in future releases of `android-activity`. It's not enough to rely on `#[non-exhaustive]` because that only really helps when adding new variants in sync with android-activity releases. On the other hand we also can't rely on a catch-all `Unknown(u32)` that only really helps with unknown variants seen at runtime. (If code were to have an exhaustive match that would include matching on `Unknown(_)` values then they wouldn't be compatible with new versions of android-activity that would promote unknown values to known ones). What we aim for instead is to have a hidden catch-all variant that is considered (practically) unmatchable so code is forced to have a `unknown => {}` catch-all pattern match that will cover unknown variants either in the form of Rust variants added in future versions or in the form of an `__Unknown(u32)` integer that represents an unknown variant seen at runtime. Any `unknown => {}` pattern match can rely on `IntoPrimitive` to convert the `unknown` variant to the integer that comes from the Android SDK in case that values needs to be passed on, even without knowing it's semantic meaning at compile time. Instead of adding an `__Unknown(u32)` variant to the `Class` enum though this enum has been removed in favour of adding methods like `is_button_class()` and `is_pointer_class()` to the `Source` type, since the class flags aren't guaranteed to be mutually exclusive and since they are an attribute of the `Source`. This removes some reliance `try_into().unwrap()` that was put in place anticipating that we would support `into()` via `num_enum`, once we could update our rust-version.
- Loading branch information