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

Clarify the format used by Display is may change #667

Closed

Conversation

softdevca
Copy link

Additional documentation that the format of display may change and should not be relied upon, as indicated as comment in #666

@jhpratt
Copy link
Member

jhpratt commented Feb 28, 2024

This is the case for any type implementing Display (in any crate) unless the documentation says it can be relied upon. The stability guarantee is what is documented, and the output is not documented as stable.

@jhpratt jhpratt closed this Feb 28, 2024
@jhpratt jhpratt added the A-docs Area: documentation label Feb 28, 2024
@softdevca
Copy link
Author

softdevca commented Feb 28, 2024

I am unable to find any documentation the format of fmt::Display is unstable. Not in the documentation for the Rust API (including alloc and core), not in the Rust book or anywhere else. It may be true that colloquially Display cannot be relied upon but I respectfully believe it would be clearer if it was made explicit. If for no other reason than to assist new users of the time crate .

@jhpratt
Copy link
Member

jhpratt commented Feb 29, 2024

So long as the output is correct, any value is valid. The lack of a stability promise implies instability. This is semantic versioning, which deals with public API. In the case of time (and most Rust crates), this public API exists in the form of documentation. No where have I documented (and asserted the unchanging nature of) the output of Display, so it is simply not subject to semver.

@softdevca
Copy link
Author

Thank you for the clear and fair explanation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-docs Area: documentation
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants