-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
[API Proposal]: Stringbuilder.Replace(ROS oldValue, ROS newValue, int index, int count) #77837
Comments
Tagging subscribers to this area: @dotnet/area-system-runtime Issue DetailsBackground and motivationI am operating a lot with spans and slicees and I would super like to not get forced to write-out the span to a string by "builder.ToString()", if possible. It would save tremendous allocations cause when working in game dev /graphics related stuff , the amount of calls which happen per second make up a significant GC-pressure, so would be nice to avoid that. API Proposal public StringBuilder Replace(ReadOnlySpan<char> oldValue, ReadOnlySpan<char> newValue, int startIndex, int count)
public StringBuilder Replace(ReadOnlySpan<char> oldValue, ReadOnlySpan<char> newValue) API Usagestring input = "Hello world";
ROS charSpan = bigString.Slice(0, 5);
ROS replacer = stackalloc char[] {'d', 'e', 'a', 'r'};
StringBuilder builder = new(input);
builder.Replace(charSpan, replacer); Alternative DesignsDue to backward compatibility, it would be only an option to add a new API. RisksAFAIK none.
|
May I know if this API proposal could be something for .net 8 release? thx in advance and coolio work you have put in this .NET thing! |
These won't make .NET 8, which is all but done at this point. But the proposal looks reasonable for .NET 9. I've marked it as ready for review. Thanks. |
Any chance btw to adapt this proposal also for the "AppendJoin()" and "AppendFormat()" methods which still take only string, considering that StringBuilder is used most of the time in high allocation-pressured code , I assume this could be a reasonable adaption aswell. |
Please open a separate issue with supporting details, real examples of where it'd be helpful, etc. Thanks. |
Not gonna lie I have already had your answer in mind when i was typing, so thats on me ^^. |
Just to see how easy it would be to implement something like this, I've already attempted an implementation (see commit below). Was able to change the current implementation with Not sure if it's the way you want to go with it, but was educational for me either way. Provided that this gets through the review meeting, I'd be interested to take a crack at this issue. Apologies for the original response below, I misunderstood what you're trying to do (a
runtime/src/libraries/System.Private.CoreLib/src/System/String.Manipulation.cs Lines 1110 to 1116 in 8e1e6f5
|
Converted the StringBuilder.Replace(string, string, int, int) method and underlaying methods to take ReadOnlySpan<char> as arguments instead. The Replace methods with string arguments create spans to use the same new method. Fix dotnet#77837
Looks good as proposed. namespace System.Text;
partial class StringBuilder
{
public StringBuilder Replace(ReadOnlySpan<char> oldValue, ReadOnlySpan<char> newValue, int startIndex, int count);
public StringBuilder Replace(ReadOnlySpan<char> oldValue, ReadOnlySpan<char> newValue);
} |
Fixes #77837 Co-authored-by: Max Klaversma <max.klaversma@vandoren.nl> Co-authored-by: Adam Sitnik <adam.sitnik@gmail.com>
will this be ready for .NET 9 or maybe earlier? |
It will be part of .NET 9. We don't backport new features to versions that were already shipped (.NET 8 RTM was shipped 2 weeks ago) |
Background and motivation
I am operating a lot with spans and slicees and I would super like to not get forced to write-out the span to a string by "builder.ToString()", if possible.
It would save tremendous allocations cause when working in game dev /graphics related stuff , the amount of calls which happen per second make up a significant GC-pressure, so would be nice to avoid that.
API Proposal
API Usage
Alternative Designs
Due to backward compatibility, it would be only an option to add a new API.
Risks
AFAIK none.
The text was updated successfully, but these errors were encountered: