Skip to content

Improve ergonomics of (*)MessageKind's #6

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
Snowda opened this issue Dec 26, 2022 · 1 comment
Open

Improve ergonomics of (*)MessageKind's #6

Snowda opened this issue Dec 26, 2022 · 1 comment

Comments

@Snowda
Copy link

Snowda commented Dec 26, 2022

Due to how the variants of MessageKind and ADSBMessageKind are built, they are pretty easy to create, but from a user of the API's perspective, due to the individual variants being Enums, they cannot be typed and assigned to new variables.

I'd suggest to convert messageKinds into individual types, but they consumes a common trait that can still be extended using impl on both of these types for creation purposes. This is particularly impactful on the enum variants that have highly differing contents and sub-fields. By implementing this, in theory you could then the following which is not really possible as Enums aren't types:

let packet = parse_avr(&input).unwrap();
let adsb: ADSBMessage = packet.kind;
let postition: Position = adsb.kind.cpr_frame.position;
@asmarques
Copy link
Owner

Unfortunately rust doesn't support enum variants as types and it looks like this won't be changing anytime soon (rust-lang/lang-team#122).

Another alternative to improve the ergonomics of assigning message types would be to convert the anonymous struct variants into tuple variants containing a named struct:

struct AirbornePosition {
    altitude: u16,
    cpr_frame: CPRFrame,
}

pub enum ADSBMessageKind {
    ...
    AirbornePosition(AirbornePosition),
    ...
}

Despite the more verbose syntax for matching/creating, would this help your use case?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants