ClientModel: Release Azure.Variant in the Azure.Core package

[heaths]

Feature Description

Azure.Variant is an implementation of a tagged union. It provides a type we can use for both primitives and value types to avoid boxing .NET intrinsic types. For example, in libraries like KeyVault mentioned below, it could be used to hold both a string and an int without boxing the int.

API Proposal

dotnet/runtime#28882

Additions we'd like to make

• Improved UX for nulls
• Improved debugger viewing
• Allow reference type values, e.g. string, to return null from As<T> without throwing
• Don't allow setting Variant to a Variant
  The following code should print "System.String", but it prints "Azure.Value":

    var value1 = new Value("hi");
    var value2 = new Value(value1);
    Console.WriteLine(value2.Type);

• Support numeric conversions, e.g.:
  If a cast from S to D works in standard C# code, it should work when S is stored in Variant.

    var value2 = new Value(1);
    object int64 = value2.As<long>();

Libraries we expect to use it

• JobRouter
• Azure.Core
  • to expand DynamicData to types other than JSON
  • possibly to reduce the set of APIs on MutableJsonElement

[christothes]

Do we have any other context on the Azure.Value type?

[heaths]

@KrzysztofCwalina and @tg-msft asked me to consider using it for an upcoming KV release, but seems it won't make it in time. They asked me to open a tracking issue.

[annelo-msft]

Per @KrzysztofCwalina:

The following package GA is blocked on this. We want to not ship this type and use Value instead: https://apiview.dev/Assemblies/Review/e1389ac1af984a86a079127e8093937a#Azure.Communication.JobRouter.LabelValue

[annelo-msft]

Filling in some context:

• KeyVault has shipped a KeyVaultSettingValue type that would have used Azure.Value if it had been available. Usage samples for that are here.
• Azure.Communication.JobRouter.LabelValue has some samples here
• The original PR for Azure.Value is here: Added Value (variant) Type #27487
• Original API Proposal by @JeremyKuhne is here: API Proposal: Add type to avoid boxing .NET intrinsic types dotnet/runtime#28882

[heaths]

KeyVaultSettingValue does do one thing a little differently than Value, and it may or may not be worth considering. To avoid polymorphic types for a single value, we recommended a type: string property for the value. Any primitive can encode as a string, so this avoided more complexity in the generated models we use as an HLC. Thus, ToString always returns the string-formatted value, and customers can set a string. This allows a customer on an older SDK version to read/write values that are added to the service, which are not part of the schema (the key/value pairs themselves).

Maybe Value is meant more for polymorphic types, but this might be something to consider. At least when I opened this tracking issue, Value did not support an everything-as-a-string fallback.

[annelo-msft]

A service team has asked how they can indicate in a swagger or typespec file that Value should be used in a model - it would be good to provide a solution to this.

[annelo-msft]

@KrzysztofCwalina, we should touch-base on whether or not this is currently a priority, and if so, what our approach is now given System.ClientModel