Add additional methods to ConditionalWeakTable

[stephentoub]

ConditionalWeakTable<T> is a specialized dictionary but it lacks several useful public members. We just added AddOrUpdate in https://github.com/dotnet/corefx/issues/8429. We should also add:

public sealed class ConditionalWeakTable<TKey,TValue> : IEnumerable<KeyValuePair<TKey,TValue>>
{
    public void Clear(); // already exists as internal, just needs to be made public
    IEnumerator<KeyValuePair<TKey,TValue>> IEnumerable<KeyValuePair<TKey,TValue>>.GetEnumerator(); // non-snapshot semantics, similar to ConcurrentDictionary
    IEnumerator IEnumerable.GetEnumerator();
}

[justinvp]

I don't have an opinion either way, but I seem to recall a deliberate choice to not implement any of the collection/dictionary interfaces and not treat ConditionalWeakTable as a "collection" when it was originally designed. I can't remember the specific details on why... Maybe because keys aren't persisted and keys/values are automatically removed.

We could expose GetEnumerator() and a struct enumerator without implementing any collection interfaces, which would enable foreach for code that needs it, without turning it into a general-purpose collection.

[stephentoub]

I've been thinking about how to best implement the enumerator, and all of the safe implementations I've thought of necessitate having a finalizer in case Dispose isn't called. As such, for now at least I'm removing the struct enumerator from the proposal. We can explicitly implement IEnumerable<KeyValuePair<TKey,TValue>>, such that if in the future we find a better way to implement this entirely allocation-free, we can do so without it being breaking.

[terrajobst]

What's the scenario for iterating over it? There are some concerns that making ConditionalWeakTable<K,V> a general purpose collection is pushing its design in a direction we don't believe makes sense.

[stephentoub]

@terrajobst, why don't you believe it makes sense?

Examples:

• Debugging, and wanting to show everything in the table, as TaskScheduler needs to elsewhere in mscorlib
• Timing out entries, iterating through the table to find entries older than some time and forcibly removing entries from the cache;
• It already has an internal Keys and Values property because iteration was needed elsewhere in mscorlib, so examples similar to those
• Finding entries by value rather than by key, so scenarios similar to dictionary's ContainsValue
• Using a different equality operation on keys, as WinRT event code does elsewhere in mscorlib
• ...

[terrajobst]

We concluded that @stephentoub will take a look whether we can actually implement these APIs without holding references for too long. If we can, the API seem fine as proposed.