Consider using interceptors for IndexOfAny-like calls

[MihaZupan]

dotnet/roslyn-analyzers#6898 is adding an analyzer that will flag uses like

const string MyValues = "abcdef";

span.IndexOfAny(MyValues);

and offer a fixer to replace it with

private static readonly SearchValues<char> s_myValues = SearchValues.Create(MyValues);
const string MyValues = "abcdef";

span.IndexOfAny(s_myValues);

For patterns like these, we should consider using interceptors to automagically rewrite them to use SearchValues, without requiring the user to extract the values to a field.
The logic could also be smarter and rewrite the above example to use IndexOfAnyInRange directly instead.

This would also help projects that multi-target to TFMs that don't have SearchValues, as it would let them take advantage of the perf improvements without extra #if #elses.

Tagging subscribers to this area: @dotnet/area-system-memory
See info in area-owners.md if you want to be subscribed.

Issue Details

---

dotnet/roslyn-analyzers#6898 is adding an analyzer that will flag uses like

const string MyValues = "abcdef";

span.IndexOfAny(MyValues);

and offer a fixer to replace it with

private static readonly SearchValues<char> s_myValues = SearchValues.Create(MyValues);
const string MyValues = "abcdef";

span.IndexOfAny(s_myValues);

For patterns like these, we should consider using interceptors to automagically rewrite them to use SearchValues, without requiring the user to extract the values to a field.

This would also help project that multi-target to TFMs that don't have SearchValues, as it would let them take advantage of the perf improvements without extra #if #elses.

Author:	MihaZupan
Assignees:	-
Labels:	area-System.Memory
Milestone:	-

[adamsitnik]

It sounds reasonable, but does it have any downsides? Like longer startup (initialization of a static field) etc? If so, how could we tell whether it should be applied to all possible places or only selected ones?

[MihaZupan]

Yes, it could affect startup somewhat. Creating the SearchValues themselves is pretty cheap (order of 100s of ns), so my guess is that any runtime costs of having extra fields / cctors could show up.
I wouldn't expect users to have too many such instances in their apps though.

[MihaZupan]

Probably a more interesting use case for this now would also be replacing IndexOf("literal")/Contains("literal"), where using SV is an incremental improvement, but one that usually isn't worth making code less readable for.