Suggestion: Make try functions default

[Snowiiii]

Hello. I want to Suggest replacing all existing with Safe ones like implemented in 3ab876f. I have no idea why it was decided to make this Library panic especially if people are often using it in critical infrastructure like Servers (like i do).

You could probably come up with the argument that some people don't need checks and that would increase runtime speed, Which is true. So i think the best solution would be to add non-checking function named _unchecked like the rust std has.

[seanmonstar]

We don't need to argue one way or the other, that's been done in several other issues.

But, what exactly do you mean by making the functions default? What is the code change within the repo, exactly, that you're suggesting?

[Snowiiii]

We don't need to argue one way or the other, that's been done in several other issues.

But, what exactly do you mean by making the functions default? What is the code change within the repo, exactly, that you're suggesting?

I'm suggesting to have the checks in the "default" get function. So for example
fn get_u8(&mut self) -> u8
becomes
fn get_u8(&mut self) -> Option<u8>
but also add unchecked functions
fn get_u8_unchecked(&mut self) -> u8 // The same thing as the current get_u8

[Darksonn]

This is not possible because it's a breaking change. Due to the use of the semver hack, it cannot be done as part of #758 either because the semver hack does not allow renaming trait methods.

[Snowiiii]

This is not possible because it's a breaking change. Due to the use of the semver hack, it cannot be done as part of #758 either because the semver hack does not allow renaming trait methods.

1. You made an issue named "Call for breaking changes" and now telling me that

This is not possible because it's a breaking change

I think since this is a major version release its fine to have breaking changes which don't work using the semver hack.

[Darksonn]

No, it is absolutely necessary for the breaking change to be compatible with the semver hack. It's critical that Tokio is able to upgrade from bytes v1 to v2 in a non-breaking manner, which is only possible if we use the semver hack. The semver hack allows some kinds of breaking changes such as:

• Introducing new feature flags.
• Renaming structs and traits.
• Changing which modules hold which things.

However, other breaking changes such as renaming or removing trait methods, are not possible with the semver hack.

The call for breaking changes reiterates this:

The issue must explain why your breaking change is possible to carry out when we are using the semver hack.