[Unbranded Client CodeGen] Support basic visibility handling in client library code generation

[lirenhe]

Clear and concise description of the problem

Based on the discussion, currently we agree on

1. Ignore any handling for visibility('create')
2. Visibility none, we should delete the property

More tasks will be added if we found challenges for supporting other kind of visibility.

Actions

Preview Give feedback

1. For client, visibility("none") should make the property disapear Azure/typespec-azure#1916
   lib:tcgc +1
   

Checklist

• Follow our Code of Conduct
• Read the docs.
• Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

[JoshLove-msft]

@lirenhe, can you clarify what is meant by

Ignore any handling for visibility('create')

For .NET, we were thinking of handling visibility as outlined in #5175

[lirenhe]

@lirenhe, can you clarify what is meant by

Ignore any handling for visibility('create')

For .NET, we were thinking of handling visibility as outlined in #5175

@JoshLove-msft, If we take the generated code of .NET from TypeSpec-ToDo today, https://github.com/allenjzhang/typespec-e2e-demo/blob/main/todoApp/spec/main.tsp

There is a model of 'CreateResponse1' as part of the SDK.

https://github.com/allenjzhang/typespec-e2e-demo/blob/05c4c8d01281d4e1d2167e889c45b68000fd3492/todoApp/clients/dotnet/src/Generated/Users.cs#L82

Based on my conversation with @lmazuel, fix naming issue introduced by visibility('create') is considered as low priority for TypeSpec E2E experience. Also it won't impact any of your design around visibility.

Please let me know if you have further questions. thanks

[lmazuel]

@lirenhe I want to close that issue, here's why:

• create and none should be two issues
• create is out of scope for E2E
• none has been fixed in TCGC 0.48.3

[lirenhe]

Close this item as all language verified 'none' has been fixed.