Open heaths opened 1 year ago
Do we have any other context on the Azure.Value
type?
@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.
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
Filling in some context:
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.
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.
@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
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
https://github.com/dotnet/runtime/issues/28882
Additions we'd like to make
As<T>
without throwingLibraries we expect to use it