API proposal: Introduce a strongly-typed diagnostic properties

Background and Motivation

Communication between analyzers and their corresponding codefixes is a very common scenario. Currently there is Diagnostic.Properties property that we can set via the properties parameter on Diagnostic.Create method. However, the existing Properties is a dictionary of string, string. This is often not sufficient.

Proposed API

Option 1

 namespace Microsoft.CodeAnalysis
 {
+    public abstract class Diagnostic<TKey, TValue> : Diagnostic, IEquatable<Diagnostic<TKey, TValue>>, IFormattable
+    {
+        public ImmutableDictionary<TKey, TValue> GenericProperties { get; } // Or, TypedProperties, or some other suitable name
+    }
 }

Option 2

 namespace Microsoft.CodeAnalysis
 {
     public abstract class Diagnostic : IEquatable<Diagnostic>, IFormattable
     {
+        public ImmutableDictionary<object, object> ObjectProperties { get; } // Possibly need to find a better name
     }
 }

Usage Examples

// Analyzer code
context.ReportDiagnostic(Diagnostic<string, ISymbol>.Create(...));

// Codefix
if (context.Diagnostics[0] is Diagnostic<string, ISymbol> diagnostic)
{
    // Do work using diagnostic.GenericProperties
}

Alternative Designs

Risks

[CyrusNajmabadi]

It’s not exposed publicly, but I thought serialization would includes private members as well?

It itself is not serialized (and being an internal member and not part of the public api), cannot be observed.

Anyway, is there some way to overcome those concerns (even by a different proposal)? or it’s simply “impossible”?

I’m def not sure. The benefit of string/string is that it forces the type (and the users) to be able to put in data that is sure to serialize and sure to act as a pure value. It would need a very strong API and design to no longer have that. 😃

[Youssef1313]

It’s not exposed publicly, but I thought serialization would includes private members as well?

Anyway, is there some way to overcome those concerns (even by a different proposal)? or it’s simply “impossible”?