Azure Core template defines quite a few scalars to define something special to azure, such as azureLocation, armId, etc.
Currently they are treated as if they are built-in type with their own "kind".
This is not a way that could be extended because every time when there is a new scalar, we will have to update TCGC to adopt it otherwise the new information will be completely discarded, and the downstream SDKs will only get its underlying types.
We could do the following change to make the scalars extensible, such as:
interface SdkScalarType extends SdkTypeBase {
name: string;
namespace: string;
underlyingType: SdkBuiltinType; // or call it wireType just as duration and datetime?
}
And all those scalars, will be parsed into these new scalar types instead of built-in types, in the downstream SDKs, we could do (taking dotnet as example):
Azure Core template defines quite a few scalars to define something special to azure, such as
azureLocation
,armId
, etc.Currently they are treated as if they are built-in type with their own "kind". This is not a way that could be extended because every time when there is a new scalar, we will have to update TCGC to adopt it otherwise the new information will be completely discarded, and the downstream SDKs will only get its underlying types.
We could do the following change to make the scalars extensible, such as:
And all those scalars, will be parsed into these new scalar types instead of built-in types, in the downstream SDKs, we could do (taking dotnet as example):
In this way, the extensible part could only happen in the downstream SDK generator part, and TCGC never needs a new version for such a requirement.