Add support for custom allocator for (C)String#79500
Closed
TimDiekmann wants to merge 3 commits intorust-lang:masterfrom
Closed
Add support for custom allocator for (C)String#79500TimDiekmann wants to merge 3 commits intorust-lang:masterfrom
(C)String#79500TimDiekmann wants to merge 3 commits intorust-lang:masterfrom
Conversation
rust-highfive
added
the
S-waiting-on-review
rustbot
added
A-allocators
15 tasks
Member
|
CI seems to be failing. |
Member
Author
|
@rustbot modify labels: +S-blocked |
rustbot
added
the
S-blocked
Collaborator
|
☔ The latest upstream changes (presumably #80510) made this pull request unmergeable. Please resolve the merge conflicts. |
DJMcNab
added a commit
to DJMcNab/retain_more
that referenced
this pull request
Dec 31, 2020
JohnCSimon
added
S-waiting-on-author
camelid
removed
the
S-waiting-on-author
Contributor
|
@TimDiekmann Is there a workaround until this is merged to have owned |
Member
Author
No, sorry. You can implement/use a custom |
|
Any chance this could happen soonish? |
10 tasks
Contributor
|
@TimDiekmann I made an initial partial re-implementation of this PR (#101551) on the current master branch using the workaround(?) I mentioned in the blocking issue. |
Member
Author
|
I currently don't have the time to rebase this branch, I'm sorry 🙁 Feel free to base on this branch or whatever is the easiest for you 🙂 |
JonathanBrouwer
added a commit
to JonathanBrouwer/rust
that referenced
this pull request
Mar 2, 2026
Add `String<A>` type with custom allocator parameter This change is part of the `allocator_api` feature set [rust-lang#32838](rust-lang#32838) (also see [wg-allocators roadmap] or [libs-team ACP]). The previous attempts at adding an allocator parameter to string are at [rust-lang#101551], and [rust-lang#79500] (I think those authors should get much of the credit here, I am re-writing what they worked out in those threads). ## workaround There is a type inference ambiguity introduced when adding a generic parameter to a type which previously had none, even when that parameter has a default value (more details in [rust-lang#98931]). I've done the same [workaround] as [rust-lang#101551], which is to make `alloc::string::String` a type alias to `String<Global>`, but I've arranged the modules a bit differently to make rebase/merges a bit easier. This workaround unfortunately changes the type name of the `String` language item, and that would be user-facing in error or diagnostic output. I understand from [this comment](rust-lang#101551 (comment)) that this change is acceptable. ## changes to existing API Most of the methods on the original `String` have been implemented for the generic version instead. I don't foresee anything more moving from `String<Global>` to `String<A>`, as the remaining methods are all constructors which implicitly use the `Global` allocator. There are three general types of changes: 1. methods which don't allocate: here we just change `impl Foo for String` to `impl<A: Allocator> Foo for String<A>` 2. converting to/from other allocator generic types like `Vec<u8, A>` and `Box<str, A>`: here we can use the existing allocator from those types. 3. methods which clone from some other type with an allocator: here it's ambiguous whether the end result should be `String<A>`, `String<Global>`, or `String<impl Allocator + Default>`, etc; in general I try to leave these out of this change, but where some analogous change was made to `Vec<T, A>` I follow that. ## new methods Some methods have been added to `String<A>` which are not strictly necessary to land this change, but are considered helpful enough to users, and close enough to existing precedent in `Vec<T, A>`. Specifically, 4 new constructors (`new_in`, `with_capacity_in`, `try_with_capacity_in`, `from_raw_parts_in`), 1 destructor (`into_raw_parts_with_alloc`), and 1 getter (`allocator`). Technically, the updated `from_utf8_unchecked` should be sufficient for constructing, but we can add some safe constructors so users don't have to sully themselves. ## not implemented Variants of `from_utf{8,16}*` which internally allocate or use `Cow` have been punted on this PR, maybe a followup would make sense to either rewrite them, or add some `*_in` variant. [wg-allocators roadmap]: rust-lang/wg-allocators#7 [libs-team ACP]: rust-lang/libs-team#101 [workaround]: rust-lang#79499 (comment) [rust-lang#101551]: rust-lang#101551 [rust-lang#79500]: rust-lang#79500 [rust-lang#98931]: rust-lang#98931
JonathanBrouwer
added a commit
to JonathanBrouwer/rust
that referenced
this pull request
Mar 2, 2026
Add `String<A>` type with custom allocator parameter This change is part of the `allocator_api` feature set [rust-lang#32838](rust-lang#32838) (also see [wg-allocators roadmap] or [libs-team ACP]). The previous attempts at adding an allocator parameter to string are at [rust-lang#101551], and [rust-lang#79500] (I think those authors should get much of the credit here, I am re-writing what they worked out in those threads). ## workaround There is a type inference ambiguity introduced when adding a generic parameter to a type which previously had none, even when that parameter has a default value (more details in [rust-lang#98931]). I've done the same [workaround] as [rust-lang#101551], which is to make `alloc::string::String` a type alias to `String<Global>`, but I've arranged the modules a bit differently to make rebase/merges a bit easier. This workaround unfortunately changes the type name of the `String` language item, and that would be user-facing in error or diagnostic output. I understand from [this comment](rust-lang#101551 (comment)) that this change is acceptable. ## changes to existing API Most of the methods on the original `String` have been implemented for the generic version instead. I don't foresee anything more moving from `String<Global>` to `String<A>`, as the remaining methods are all constructors which implicitly use the `Global` allocator. There are three general types of changes: 1. methods which don't allocate: here we just change `impl Foo for String` to `impl<A: Allocator> Foo for String<A>` 2. converting to/from other allocator generic types like `Vec<u8, A>` and `Box<str, A>`: here we can use the existing allocator from those types. 3. methods which clone from some other type with an allocator: here it's ambiguous whether the end result should be `String<A>`, `String<Global>`, or `String<impl Allocator + Default>`, etc; in general I try to leave these out of this change, but where some analogous change was made to `Vec<T, A>` I follow that. ## new methods Some methods have been added to `String<A>` which are not strictly necessary to land this change, but are considered helpful enough to users, and close enough to existing precedent in `Vec<T, A>`. Specifically, 4 new constructors (`new_in`, `with_capacity_in`, `try_with_capacity_in`, `from_raw_parts_in`), 1 destructor (`into_raw_parts_with_alloc`), and 1 getter (`allocator`). Technically, the updated `from_utf8_unchecked` should be sufficient for constructing, but we can add some safe constructors so users don't have to sully themselves. ## not implemented Variants of `from_utf{8,16}*` which internally allocate or use `Cow` have been punted on this PR, maybe a followup would make sense to either rewrite them, or add some `*_in` variant. [wg-allocators roadmap]: rust-lang/wg-allocators#7 [libs-team ACP]: rust-lang/libs-team#101 [workaround]: rust-lang#79499 (comment) [rust-lang#101551]: rust-lang#101551 [rust-lang#79500]: rust-lang#79500 [rust-lang#98931]: rust-lang#98931
JonathanBrouwer
added a commit
to JonathanBrouwer/rust
that referenced
this pull request
Mar 2, 2026
Add `String<A>` type with custom allocator parameter This change is part of the `allocator_api` feature set [rust-lang#32838](rust-lang#32838) (also see [wg-allocators roadmap] or [libs-team ACP]). The previous attempts at adding an allocator parameter to string are at [rust-lang#101551], and [rust-lang#79500] (I think those authors should get much of the credit here, I am re-writing what they worked out in those threads). ## workaround There is a type inference ambiguity introduced when adding a generic parameter to a type which previously had none, even when that parameter has a default value (more details in [rust-lang#98931]). I've done the same [workaround] as [rust-lang#101551], which is to make `alloc::string::String` a type alias to `String<Global>`, but I've arranged the modules a bit differently to make rebase/merges a bit easier. This workaround unfortunately changes the type name of the `String` language item, and that would be user-facing in error or diagnostic output. I understand from [this comment](rust-lang#101551 (comment)) that this change is acceptable. ## changes to existing API Most of the methods on the original `String` have been implemented for the generic version instead. I don't foresee anything more moving from `String<Global>` to `String<A>`, as the remaining methods are all constructors which implicitly use the `Global` allocator. There are three general types of changes: 1. methods which don't allocate: here we just change `impl Foo for String` to `impl<A: Allocator> Foo for String<A>` 2. converting to/from other allocator generic types like `Vec<u8, A>` and `Box<str, A>`: here we can use the existing allocator from those types. 3. methods which clone from some other type with an allocator: here it's ambiguous whether the end result should be `String<A>`, `String<Global>`, or `String<impl Allocator + Default>`, etc; in general I try to leave these out of this change, but where some analogous change was made to `Vec<T, A>` I follow that. ## new methods Some methods have been added to `String<A>` which are not strictly necessary to land this change, but are considered helpful enough to users, and close enough to existing precedent in `Vec<T, A>`. Specifically, 4 new constructors (`new_in`, `with_capacity_in`, `try_with_capacity_in`, `from_raw_parts_in`), 1 destructor (`into_raw_parts_with_alloc`), and 1 getter (`allocator`). Technically, the updated `from_utf8_unchecked` should be sufficient for constructing, but we can add some safe constructors so users don't have to sully themselves. ## not implemented Variants of `from_utf{8,16}*` which internally allocate or use `Cow` have been punted on this PR, maybe a followup would make sense to either rewrite them, or add some `*_in` variant. [wg-allocators roadmap]: rust-lang/wg-allocators#7 [libs-team ACP]: rust-lang/libs-team#101 [workaround]: rust-lang#79499 (comment) [rust-lang#101551]: rust-lang#101551 [rust-lang#79500]: rust-lang#79500 [rust-lang#98931]: rust-lang#98931
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
10 participants
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.
This follows the roadmap of the allocator WG to add custom allocators to collections.
currently blocked on:
r? @Amanieu
cc @rust-lang/wg-allocators
@rustbot modify labels: +A-allocators +T-libs