Future of StatusCode::as_str
还没有人认领这个 Issue。
评估
- 难度
- 5/5
- 预计耗时
- 一周以上
- 新手友好度
- 25/100
- Issue 类型
- 重构
- 描述清晰度
- 需要澄清
- 活跃度
- 停滞
- 技术栈
- rust
- 领域
- networking
调研方向
从 StatusCode::as_str 方法开始，阅读所引用的 PR #380、#436 和 #466，以及 #443 上链接的讨论。比较保留、更改、弃用或删除该方法的理由，包括其二进制大小成本；完成意味着项目已就方向达成一致，并有可执行的后续工作。
由索引模型根据 Issue 内容生成。
描述
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 theDisplayimpl 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 forHTTP/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.
- 主要语言
- Rust
- 星标
- 1.4k
- 派生
- 385
- 平均合并
- 1 天 5 小时
- 30 天内合并 PR
- 2
环境准备
这个项目没有提供开发容器、Dockerfile 或贡献指南，环境需要你自己搭建：先看它的 README，通用步骤见我们的新手贡献指南。
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
hyperium/http 的其他 Issue
-
难度 2/5 1-3 小时 新手友好度 68/100
-
难度 3/5 1-2 天 新手友好度 52/100
-
难度 4/5 3-5 天 新手友好度 45/100
-
难度 3/5 1-2 天 新手友好度 62/100
-
难度 3/5 1-2 天 新手友好度 58/100
相似的 Issue
-
documentation P2
难度 2/5 1-3 小时 新手友好度 88/100
维护者通常 1 天内回复
-
bug good first issue priority:high
难度 2/5 1-3 小时 新手友好度 88/100
Konfirm-xyz/konfirm-contracts#163 ·
维护者通常 1 天内回复
-
area:gc-repack-output bug factory:dogfood factory:triaged priority:p3 type:bug type:ux
难度 2/5 1-3 小时 新手友好度 72/100
gitbutlerapp/grit#1161 · 1 条评论 ·
维护者通常 1 天内回复
-
bug
难度 2/5 1-3 小时 新手友好度 76/100
维护者通常 1 天内回复
-
feature performance
难度 2/5 1-3 小时 新手友好度 65/100
lance-format/lance#10137 ·
维护者通常 2 天内回复