add decorator for optional fields in protobuf emitter

[w01fgang]

Add optional field decorator.

Fixes #4311

[microsoft-github-policy-service]

Hi @w01fgang. Your PR has had no update for 30 days and it is marked as a stale PR. If it is not updated within 30 days, the PR will automatically be closed. If you want to refresh the PR, please remove the stale label.

[witemple-msft]

Hey @w01fgang, I'm sorry I haven't been able to catch up on this in a while. I've given this some thought, and I think we can just use TypeSpec's built-in optionality for this.

My understanding of the optional modifier is that it only controls the presence discipline of fields where the type is not a message. This modifier did not exist in the proto3 language guide when @typespec/protobuf was created, but it clearly does now. I think we can just use TypeSpec optionality to control the presence of this modifier and there won't be any risk to that, even though the concept of TypeSpec optionality and proto3 optional are not the same concept. The TypeSpec concept of optional is a stronger concept, but it makes sense to me that any field that is optional in TypeSpec should also be optional in Protobuf.

In the future, code generators that implement Protobuf from TypeSpec directly (we don't have plans for this currently, but it should be possible) could use TypeSpec optionality to do more extended validation of message-typed fields as well.

What do you think?

[microsoft-github-policy-service]

Hi @w01fgang. Your PR has had no update for 30 days and it is marked as a stale PR. If it is not updated within 30 days, the PR will automatically be closed. If you want to refresh the PR, please remove the stale label.

[Stanzilla]

Hey @w01fgang, I'm sorry I haven't been able to catch up on this in a while. I've given this some thought, and I think we can just use TypeSpec's built-in optionality for this.

My understanding of the optional modifier is that it only controls the presence discipline of fields where the type is not a message. This modifier did not exist in the proto3 language guide when @typespec/protobuf was created, but it clearly does now. I think we can just use TypeSpec optionality to control the presence of this modifier and there won't be any risk to that, even though the concept of TypeSpec optionality and proto3 optional are not the same concept. The TypeSpec concept of optional is a stronger concept, but it makes sense to me that any field that is optional in TypeSpec should also be optional in Protobuf.

In the future, code generators that implement Protobuf from TypeSpec directly (we don't have plans for this currently, but it should be possible) could use TypeSpec optionality to do more extended validation of message-typed fields as well.

What do you think?

Hey there, how would that look like, syntax wise?