HashTable use in code emitted by [GeneratedRegex]

[Atulin]

I added the BannedApisAnalyzer to my project to ban all the obsolete stuff like non-generic collections, WebClient, and so on. To my surprise, I got a warning coming from RegexGenerator.g.cs file about the use of HashTable. And, sure enough, the generated code does use it, when the regex contains named capture groups.

[GeneratedRegex(@"(^|\s)(?'tag'#[\w-]{3,})($|\s)")]
private static partial Regex HashtagRegex { get; }

generates

private HashtagRegex_1()
{
    base.pattern = "(^|\\s)(?'tag'#[\\w-]{3,})($|\\s)";
    base.roptions = RegexOptions.None;
    ValidateMatchTimeout(Utilities.s_defaultTimeout);
    base.internalMatchTimeout = Utilities.s_defaultTimeout;
    base.factory = new RunnerFactory();
    base.CapNames = new Hashtable { { "0", 0 } ,  { "1", 1 } ,  { "2", 2 } ,  { "tag", 3 }  };
    base.capslist = new string[] {"0", "1", "2", "tag" };
    base.capsize = 4;
}

I checked out the source code of the generator (click) and it is, indeed, what is supposed to be emitted:

            if (rm.Tree.CaptureNumberSparseMapping is not null)
            {
                writer.Write("        base.Caps = new Hashtable {");
                AppendHashtableContents(writer, rm.Tree.CaptureNumberSparseMapping.Cast<DictionaryEntry>().OrderBy(de => de.Key as int?));
                writer.WriteLine($" }};");
            }
            if (rm.Tree.CaptureNameToNumberMapping is not null)
            {
                writer.Write("        base.CapNames = new Hashtable {");
                AppendHashtableContents(writer, rm.Tree.CaptureNameToNumberMapping.Cast<DictionaryEntry>().OrderBy(de => de.Key as string, StringComparer.Ordinal));
                writer.WriteLine($" }};");
            }

I was wondering if there's any specific reason to use a HashTable here, instead of a Dictionary<string, int>? It seemed to me that non-generic collections are kept in the language still pretty much only for backward compatibility purposes, and new code should not be using them, in favor of lists and dictionaries.

And here it is, some pretty dang new code still referencing them.

[DaZombieKiller]

The property being assigned to, Regex.CapNames, enforces use of HashTable by allocating one if you pass in any different kind of IDictionary object. Opting to use Dictionary<string, int> here would result in an additional allocation.

[stephentoub]

And that's because these properties store the data into fields that are exposed and are strongly-typed as Hashtable:

runtime/src/libraries/System.Text.RegularExpressions/src/System/Text/RegularExpressions/Regex.cs

Lines 28 to 29 in f1332ab

	protected internal Hashtable? caps; // if captures are sparse, this is the hashtable capnum->index
	protected internal Hashtable? capnames; // if named captures are used, this maps names->index

It's an unfortunate legacy design that we can't change without it being massively breaking, due to these being public (protected) surface area.

[dotnet-policy-service]

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

[Atulin]

Ah, just another case of the consequences of breaking change prevention rearing its ugly head, then. Guess I'll just have to figure out how to disable the analyzer for generated files or stop using capture groups there, no big deal.

Thanks for the answers!