[TCGC] Need a way to remove operation from TCGC

[live1206]

Clear and concise description of the problem

For .NET SDK, we have requirement to remove certain operations, such as Operations.list should always be removed as duplicated within resource manager. Right now, the best approach we have is below, details

@armResourceOperations
interface Employees {
  get is ArmResourceRead<Employee>;
}

@@access(Employees.get, Access.internal, "csharp");

But this operation still exists, .NET SDK need to handle it specifically. Is it possible to remove this operation from TCGC result? for instance,

@@access(Employees.get, Access.never, "csharp");

Or can we have a new decorator to remove an operation in TCGC?

Checklist

• [X] Follow our Code of Conduct
• [X] Check that this issue is about the Azure libraries for typespec. For feature request in the typespec language or core libraries file it in the TypeSpec repo
• [X] Read the docs.
• [X] Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

[live1206]

cc @tadelesh @m-nash @ArcturusZhang

[m-nash]

The original design goal for this was we would have an @scope decorator which simply modified the scope of any given item.

I would imagine we could do @@scope(Service.op, "~csharp"). Meaning the operation applies to everything but csharp.

[live1206]

If we handle this in .NET generator directly, the usage calculation in TCGC will miss this part and end into inaccurate usage. So, would like to still handle this in TCGC despite this requirement is only for .NET. Potentially, it could benefit the other languages.

Normally, a decorator could be applied to Type, to avoid the over complexity only apply it to Operation as needed now.

usage:

# "~" means exclude the target operation from the defined scope
@scope("~csharp")
op nameInService: void;

@scope("java")
op nameInService: void;

validation:

• throw empty-scope since there is no point to define an empty scope
• throw is-in-use if the operation itself is in use or the models/enums contained in the operation is in use, the scope change will potentially affect the use references
  • need to check if the operation is referenced in other places
  • need to check the contained models/enums are in use outside the operation
• throw exclude-target-not-existed if the target to be excluded does not exist in main.tsp
• throw include-target-existed if the target to be included already exists in main.tsp
• throw include-target-not-declared if the target to be included is not declared, the main usage of inclusion is within client.tsp by adding some extra operation declaration

effect: the operation along with everything inside(we have validation to ensure everything inside is not referenced outside this operation) will be removed from the excluded language scopes, and the usage should be calculated correctly based on this.

[live1206]

Found https://github.com/Azure/typespec-azure-pr/issues/2732 regarding scope of decorators in TCGC. I think the proposal of @scope decorator is identical to @exclude and @include with scopes, just need to extend the entity from Model to Operation | Model. And now @exclude and @include are deprecated, because we think they can be replaced by @usage and @access. So, don't feel like adding a new @scope decorator will be the approach we would take.

Another option raise from @ArcturusZhang is to use @convenientAPI, TCGC has taken care of the Model usage. .NET SDK mgmt generator just needs to omit the operation if InputOperation.GenerateConvenienceMethod is false, same behavior as DPG

[live1206]

Found Azure/typespec-azure-pr#2732 regarding scope of decorators in TCGC. I think the proposal of @scope decorator is identical to @exclude and @include with scopes, just need to extend the entity from Model to Operation | Model. And now @exclude and @include are deprecated, because we think they can be replaced by @usage and @access. So, don't feel like adding a new @scope decorator will be the approach we would take.

Another option raise from @ArcturusZhang is to use @convenientAPI, TCGC has taken care of the Model usage. .NET SDK mgmt generator just needs to omit the operation if InputOperation.GenerateConvenienceMethod is false, same behavior as DPG

After clarification with @m-nash, the negation language scope is not implemented, but not abandoned. The reason we need a new @scope decorator and it can't be replaced by the existing deprecated @include is because we can't define the behavior of @include or @exclude decorator with negation scope.

[iscai-msft]

@live1206 would you be able to contribute a design and implementation for this? Thanks!

[live1206]

@live1206 would you be able to contribute a design and implementation for this? Thanks!

Sure, will add more details with what I have been doing.