[Feature Request] Ability to reserve String capacity directly

[thatstoasty]

Review Mojo's priorities

• I have read the roadmap and priorities and I believe this request falls within the priorities.

What is your request?

As the title says, I'd like to see what the community thinks about introducing a public API to allocate String capacity ala something like my_string.reserve(new_capacity=1000)?

What is your motivation for this change?

I had a use case where I was treating a String as a buffer so I could write bytes to it, where I roughly knew what the capacity would be ahead of time. Maybe having a StringBuilder struct would be better than using String for this purpose?

This is a continuation of the conversation started on this PR: #3735 (comment)

Any other details?

No response

[martinvuyk]

String.reserve() would be super useful before concatenating a lot of Stringlike/AsBytes instances to a String, it would avoid much overhead from the __iadd__ dunders and from doing "".join(List[String]()) which would have required all items to be allocated as a string into the list, and then doing the whole concatenation.

Also I think it will be fitting to add a String(capacity=1_000) constructor.

I think we also need to implement Writer trait for List. That trait would also be useful in Span constrained to mutable Span[Byte] but that will probably be tricky given the current clunkyness of parametrized Origins.

Maybe having a StringBuilder struct would be better than using String for this purpose?

I'd rather reduce the amount of head-space people need to use the stdlib

[thatstoasty]

@martinvuyk Yep, I share the exact same thoughts!

[thatstoasty]

This change was merged into the nightly branch, closing the issue.

[JoeLoser]

This change was merged into the nightly branch, closing the issue.

Thank you! Looks like "satisfies" in 55cbae5 didn't close the issue. Typically I use "Fixes" or "Closes" which is respected by the GitHub automation.

[thatstoasty]

Ah, I didn't know there was automation around that! I'll keep that in mind for the future 🙂

[JoeLoser]

Ah, I didn't know there was automation around that! I'll keep that in mind for the future 🙂

No worries. Yeah, see https://github.blog/news-insights/product-news/closing-issues-via-commit-messages/. Old blog post but hasn't changed much I suspect.

[JoeLoser]

There's a fair bit of cleanup work we could do now to leverage the new constructor throughout the stdlib. This would have the benefit of less reaching into private data members, which is always a plus.