Skip to content
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

Enum for websocket message types #1039

Open
realwakka opened this issue May 8, 2023 · 3 comments
Open

Enum for websocket message types #1039

realwakka opened this issue May 8, 2023 · 3 comments
Labels
feature New feature or request

Comments

@realwakka
Copy link

Is your feature request related to a problem? Please describe.
I'm using warp for develop websocket server. I selected warp for web framework other than axum, actix. It's concise!.
I thought about using tokio-tungstenite. but it had some problem with handling http request.
I'm using warp very well but there is only one thing that it's ugly to write code for branching websocket message type.
Now it provides some functions like to_str() to know the message type but I think enum is better like other framework.

Describe the solution you'd like
Provide enum type for websocket message type.

Describe alternatives you've considered
I tried some other framework but it's not concise as warp.
tokio-tungstenite has not much feature as warp.

Additional context
I see the comments in the code that it will provide enum when rust supports non-exhaustive stabilized.
I don't understand that why websocket types should be non-exhaustive.
If it's hard to implement, I think it's okay to just exposure tungstenite module.

Thanks!

@realwakka realwakka added the feature New feature or request label May 8, 2023
@seanmonstar
Copy link
Owner

I don't understand that why websocket types should be non-exhaustive.

New frame types are allowed to be added, but if we made an exhaustive enum (such that you could write a match that check for every type), then when we added support for a new frame in the library, that would break your code.

@FSMaxB
Copy link
Contributor

FSMaxB commented May 8, 2023

New frame types are allowed to be added, but if we made an exhaustive enum (such that you could write a match that check for every type), then when we added support for a new frame in the library, that would break your code.

Quite a while back I made this PR: #903 (not realizing at the time that it was a duplicate already).

The concern about matching the enum is addressed by making it #[non_exhaustive].

@realwakka
Copy link
Author

@seanmonstar Thanks, I understand!
@FSMaxB Cool, I hope that the PR will be merged

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

No branches or pull requests

3 participants