Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Future of StatusCode::as_str

Đang mở
  • Có gì không ổn?
#468 11 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
25/100
Loại issue
Tái cấu trúc
Độ rõ ràng
Cần làm rõ
Mức độ hoạt động
Đình trệ
Công nghệ
rust
Lĩnh vực
networking

Hướng nghiên cứu

Bắt đầu với phương thức StatusCode::as_str và đọc các PR được tham chiếu #380, #436 và #466, cùng với cuộc thảo luận được liên kết trên #443. So sánh các lập luận ủng hộ việc giữ lại, thay đổi, đánh dấu không còn được khuyến nghị hoặc xóa phương thức này, bao gồm cả chi phí về kích thước nhị phân; được xem là hoàn tất khi dự án có định hướng đã được thống nhất và một bước tiếp theo có thể thực hiện.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

A-status B-rfc

I wanted to write-up some thoughts on the future direction for the StatusCode::as_str method. The as_str method returns the numeric part of the status code as a string slice. So, StatusCode::OK.as_str() returns "200", and StatusCode::NOT_FOUND.as_str() returns "404", and so forth. This works for all StatusCodes, from 100-999. Since the StatusCode only stores an integer, there's no field to actually borrow the string from, so it is in reality returning a &'static str, even though the method signature doesn't expose that.

There have been several PRs filed to make that part of the signature (that is, change from fn as_str(&self) -> &str to fn as_str(&self) -> &'static str) (#380 #436 #466).

I've personally questioned the value of the method in it's entirety:

I was thinking that perhaps we just axe StatusCode::as_str, because really, how useful can it be? There's the Display impl to get a string, and if you want a fast path for some common status codes, a user can just do that manually (hyper has a fast path for HTTP/1.1 200 OK, for instance).

That comment was prompted as I wondered about the cost of including all the static strings in the binary, when certainly most applications will never need them. Because I don't see value in the method, I've held off from changing it return a &'static str. Instead, I've thought we may just want to deprecate it and chop it for 1.0.

However, I realize I could be wrong, and not considering a large use case for this method. If so, we can just merge one of the PRs and carry on. If I have overlooked something, hopefully we can collect the reasons why to keep the method, with some details about the value it provides versus the cost of having a bunch of extra strings in the binary for everyone.

Ngôn ngữ chính
Rust
Star
1.4k
Fork
385
Merge trung bình
1 ngày 5 giờ
Pull request đã merge (30 ngày)
2

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của hyperium/http

Tất cả issue của hyperium/http

Issue tương tự

Thêm issue về Rust

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.