Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

Future of StatusCode::as_str

Ouverte
  • Quelque chose ne va pas ?
#468 11 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
25/100
Type d'issue
Refactorisation
Clarté
À clarifier
Activité
À l'abandon
Stack technique
rust
Domaine
networking

Piste de recherche

Commencez par la méthode StatusCode::as_str et lisez les PR référencées #380, #436 et #466, ainsi que la discussion liée sur #443. Comparez les arguments en faveur de la conservation, de la modification, de la dépréciation ou de la suppression de la méthode, y compris son coût en taille binaire ; le travail est considéré comme terminé lorsque le projet dispose d’une orientation approuvée et d’un suivi réalisable.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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.

Langage dominant
Rust
Étoiles
1.4k
Forks
385
Merge moyen
1 j 5 h
PR mergées (30 j)
2

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de hyperium/http

Toutes les issues de hyperium/http

Issues similaires

Plus d'issues Rust

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.