-
Notifications
You must be signed in to change notification settings - Fork 19
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
ACP: Implement FromIterator for Box<str> #196
Labels
ACP-accepted
API Change Proposal is accepted (seconded with no objections)
api-change-proposal
A proposal to add or alter unstable APIs in the standard libraries
T-libs-api
Comments
calebsander
added
api-change-proposal
A proposal to add or alter unstable APIs in the standard libraries
T-libs-api
labels
Mar 25, 2023
m-ou-se
added
the
ACP-accepted
API Change Proposal is accepted (seconded with no objections)
label
Mar 5, 2024
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this issue
Mar 15, 2024
…, r=dtolnay alloc: implement FromIterator for Box<str> `Box<[T]>` implements `FromIterator<T>` using `Vec<T>` + `into_boxed_slice()`. Add analogous `FromIterator` implementations for `Box<str>` matching the current implementations for `String`. Remove the `Global` allocator requirement for `FromIterator<Box<str>>` too. ACP: rust-lang/libs-team#196
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
May 18, 2024
…r=dtolnay alloc: implement FromIterator for Box<str> `Box<[T]>` implements `FromIterator<T>` using `Vec<T>` + `into_boxed_slice()`. Add analogous `FromIterator` implementations for `Box<str>` matching the current implementations for `String`. Remove the `Global` allocator requirement for `FromIterator<Box<str>>` too. ACP: rust-lang/libs-team#196
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
May 19, 2024
…r=dtolnay alloc: implement FromIterator for Box<str> `Box<[T]>` implements `FromIterator<T>` using `Vec<T>` + `into_boxed_slice()`. Add analogous `FromIterator` implementations for `Box<str>` matching the current implementations for `String`. Remove the `Global` allocator requirement for `FromIterator<Box<str>>` too. ACP: rust-lang/libs-team#196
lnicola
pushed a commit
to lnicola/rust-analyzer
that referenced
this issue
May 19, 2024
alloc: implement FromIterator for Box<str> `Box<[T]>` implements `FromIterator<T>` using `Vec<T>` + `into_boxed_slice()`. Add analogous `FromIterator` implementations for `Box<str>` matching the current implementations for `String`. Remove the `Global` allocator requirement for `FromIterator<Box<str>>` too. ACP: rust-lang/libs-team#196
RalfJung
pushed a commit
to RalfJung/miri
that referenced
this issue
May 19, 2024
alloc: implement FromIterator for Box<str> `Box<[T]>` implements `FromIterator<T>` using `Vec<T>` + `into_boxed_slice()`. Add analogous `FromIterator` implementations for `Box<str>` matching the current implementations for `String`. Remove the `Global` allocator requirement for `FromIterator<Box<str>>` too. ACP: rust-lang/libs-team#196
flip1995
pushed a commit
to flip1995/rust-clippy
that referenced
this issue
May 24, 2024
alloc: implement FromIterator for Box<str> `Box<[T]>` implements `FromIterator<T>` using `Vec<T>` + `into_boxed_slice()`. Add analogous `FromIterator` implementations for `Box<str>` matching the current implementations for `String`. Remove the `Global` allocator requirement for `FromIterator<Box<str>>` too. ACP: rust-lang/libs-team#196
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
ACP-accepted
API Change Proposal is accepted (seconded with no objections)
api-change-proposal
A proposal to add or alter unstable APIs in the standard libraries
T-libs-api
Proposal
Problem statement
Boxed slices are space-saving alternatives to
Vec
andString
when the ability to grow the allocation is not required. To make them easier replacements, it would be ideal forBox<[T]>
andBox<str>
to provide all the functionality ofVec<T>
andString
that doesn't require resizing.One functionality gap is that
String
implementsFromIterator
(for 6 types ofIterator
item), butBox<str>
doesn't. There's already an analogous implementation forBox<[T]>
:FromIterator
is implemented forBox<[T]>
by usingVec<T>
'sFromIterator
implementation and then callinginto_boxed_slice()
to convert to aBox<[T]>
. The proposal is to do the same thing forBox<str>
: provide the sameFromIterator
implementations thatString
has, which can be implemented by collecting into aString
and then callinginto_boxed_str()
.Additionally,
impl FromIterator<Box<str>> for String
andimpl Extend<Box<str>> for String
can be generalized to allow boxed strings with allocators other thanGlobal
. The implementations already copy the bytes to theString
's allocation, so they work forBox<str, A>
with anyA: Allocator
.Motivation, use-cases
The existing
impl<I> FromIterator<I> for Box<[I]>
makes it convenient to collect an iterator into a boxed slice, for example:Box<str>
is an even more useful alternative toString
thanBox<[T]>
is forVec<T>
, as strings are often immutable. The existingFromIterator<char>
implementation forString
makes it easy, for example, to reverse the characters in a string:However, returning a
Box<str>
requires a much more verbose implementation:Providing a
FromIterator
implementation forBox<str>
would allow for the same implementation as forString
.Solution sketches
An implementation is available here: rust-lang/rust#99969
The same
FromIterator
implementations as forString
are added forBox<str>
. The implementations are straightforward, usingString
'sFromIterator
implementation and then callinginto_boxed_str()
to remove the excess capacity, analogous toimpl<I> FromIterator<I> for Box<[I]>
.One other possibility is to extend the
FromIterator
implementations toBox<str, A>
for allA: Allocator
. But this is not currently done forBox<[T], A>
orVec<T, A>
, so I opted to do the same and only add implementations forBox<str>
.Links and related work
rust-lang
PR: rust-lang/rust#99969What happens now?
This issue is part of the libs-api team API change proposal process. Once this issue is filed the libs-api team will review open proposals in its weekly meeting. You should receive feedback within a week or two.
The text was updated successfully, but these errors were encountered: