Tracking issue for String::insert_str

[murarth]

Tracking issue for String::insert_str, introduced in #34771

[apasel422]

CC #35554.

[tshepang]

why is this not yet stabilised

[rhysd]

I made a workaround for this until this API is stabilised.

pub fn insert(target: &mut String, index: usize, inserted: &str) {
    for c in inserted.chars().rev() {
        target.insert(index, c);
    }
}

[SimonSapin]

@rhysd This work, but takes O(N × (M + N)) time where N = inserted.len() and M = target.len() - index. (This is because a single String::insert call takes O(M) time, since it needs to move the bytes in target after index to the right in order to make room for c.) But maybe that’s OK for you because N and M are small in your program.

String::insert_str uses unsafe code to only move bytes once, and so takes O(M + N) time.

[rhysd]

@SimonSapin yeah, N is 4 and M is 10~20. Just a workaround for this API.

[alexcrichton]

@rfcbot fcp merge

Seems like a consistent API and has baked for awhile!

[rfcbot]

Team member @alexcrichton has proposed to merge this. The next step is review by the rest of the tagged teams:

• @BurntSushi
• @Kimundi
• @alexcrichton
• @aturon
• @brson
• @sfackler

No concerns currently listed.

Once these reviewers reach consensus, this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

psst @alexcrichton, I wasn't able to add the final-comment-period label, please do so.