-
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
Prefer string.AsSpan() over string.Substring() when parsing #33784
Comments
Estimates:
|
Seems reasonable. We should figure out how much we want our analyzers (especially our on-by-default analyzers) to push people into using span. Using |
Category: Performance |
@Mrnikbobjeff also approved in case you already started working on this. Let us know if you'd like to get this issue assigned to you. |
I am currently working on porting my analyzers to be IOperation analyzers to be inline with the pattern already established. While I have a working implementation for a c# analyzer and fixer I still need to port the analyzer at least for this to be viable. |
Would you like me to assign this to you @Mrnikbobjeff or should i mark it up-for-grabs instead? |
I closed #33778 in favor of this one (it was an identical approved proposal). Note to whoever decides to work on this: Please take a look at this comment in the dup issue, since it contains a list of cases this analyzer should be able to address. |
I would like to be assigned to this. I'll start work on it immediately. |
How does one enable this Edit: It seems that the rule does not flag all uses of |
The rule should flag instances of a pattern like
int.Parse(str.Substring(...))
and instead switch to using the span-basedint.Parse(str.AsSpan(...))
. This would apply to all of the primitive types, and more generally potentially anything that has an overload taking aReadOnlySpan<char>
instead of astring
.Category: Performance
The text was updated successfully, but these errors were encountered: