Open timotheeguerin opened 11 months ago
Not sure if we can use this issue to share all the visbility related feature requirements, here's some requirements from previous discussion.
visibility should use an enumerated type rather than a string (for both model and operation visibility decorators
@visibility
@parameterVisibility
@returnTypeVisibility
@withVisibility
@withDefaultKeyVisibility
including the future planning of visibility and optionality combination https://github.com/Azure/typespec-azure/issues/1117 [in fact, everywhere that visibility is used])
TypeSpec should provide helpers to transform visibility into the information that emitters need when they are creating client models and serializing and deserializing operation requests and responses
Provide a mechanism for specifying the names of models transformed by visibility
Proposal: to extend the @clientName
decorator to support Visibility rename
@@clientName(ModelVisibility, "typescript", "ModelVisibilityCreateParameters", HttpVis.Create | HttpVis.Update)
Here's a unresolved topic from dotnet and java codegen side, which I haven't thought of a better proposal for it.
Playground Link
Things to think about:
@visibility(HttpVis.read | HttpVis.write)
@visibility
does it append or override: We definitly need some appending functionality so you can provide visibiity foir different protocol but not being able to override might be limiting.