Avoid monomorphization overhead of API convenience generics #453
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Having a `T: Into<String>` bound at the API boundaries is convenient but it implies a certain overhead if the implementation is monomorphized multiple times even though there is not functional difference to whether it has access to `T` or just `&str`. More generally speaking, using `&str` as the public type might be a better choice in any case as the implementation does not use ownership of `T` anywhere and taking a string slice would there offer the most efficient API contract, but that would be a braking change and hence I did not make it here.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Having a
T: Into<String>bound at the API boundaries is convenient but it implies a certain overhead if the implementation is monomorphized multiple times even though there is not functional difference to whether it has access toTor just&str.More generally speaking, using
&stras the public type might be a better choice in any case as the implementation does not use ownership ofTanywhere and taking a string slice would there offer the most efficient API contract, but that would be a braking change and hence I did not make it here.