[REQ][CSharp] Set EmitDefaultValue to true

[B14m3m3]

Is your feature request related to a problem? Please describe.

CSharp generated files have "EmitDefaultValue=false".

[DataContract]
    public partial class MyClass: IEquatable<MyClass>
    { 
        /// <summary>
        /// Gets or Sets MyVal
        /// </summary>
        [DataMember(Name="Unrealized",  EmitDefaultValue=false)]
        public double MyVal{ get; set; }`
        ...
    }

Describe the solution you'd like

There should be an option to not set this value (The default is true).
It looks like there is a option on https://github.com/OpenAPITools/openapi-generator/blob/master/docs/generators/csharp-refactor.md.
But i was unable to generate models with that generator.

So something like --additional-properties optionalEmitDefaultValues=true

Describe alternatives you've considered

None?

[wing328]

EmitDefaultValue's value is determined by the nullable attribute (OAS v3) in the model property. If you're still using OAS v2, please use x-nullable: true instead.

Ref:

openapi-generator/modules/openapi-generator/src/main/resources/csharp/modelGeneric.mustache

Line 34 in 26c493b

[DataMember(Name="{{baseName}}", EmitDefaultValue={{#isNullable}}true{{/isNullable}}{{^isNullable}}false{{/isNullable}})]

[B14m3m3]

This means, all nullable: false omit default values, meaning if i have a number, say:

 MyDouble:
          type: number
          format: double
          nullable: false
          example: 0.0

I would still want it to explicitly write "MyDouble": 0.0 in my api result. But i am unable to do that?

[wing328]

Are you referring to the default value instead?

If I remember correctly, default values are not included in the client's model as the server should take care of these default values.

[B14m3m3]

Well in this case the value "0.0" would be the default value and thus omitted in the result.

A concrete example:

A simple subtraction service takes 2 values as input, and should return the result.

If a client sends {"value1": 2.0, "value2": 2.0}.
Then the server should reply with {"result": 0.0}.
The result cannot be nullable, thus nullable: false, and since 0.0 is the default value it will omit the result thus only returning {}. This means a client would have to infer the 0.0 (which is possible). But i would personally prefer the explicitness of the actual 0.0 value.

[wing328]

From what I understand, nullable value is just null (not false, 0.0): https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.2.md#fixed-fields-20

[B14m3m3]

I agree, a nullable value can be null.

But returning a nullable field in this case makes no sense, right? Either you throw a hard error. Or you produce a correct result of the calculation, thus the resulting double is always a value never null. Thus setting nullable: false, should make sense?

The default value of a double in c# is 0.0 afterall. Meaning if you set EmitDefaultValue of a double(not double? if nullable is set to true) to false. It will not emit a property when it's 0.0.

double? -> default value is null - Per default this sets emit default value to true so no big deal.
double -> default value is 0.0 - I still want to emit this.

[wing328]

double -> default value is 0.0 - I still want to emit this.

One solution is to customize the templates with the -t option and hard code EmitDefaultValue to true.

[B14m3m3]

I will try to look into it monday. Thanks looking into it with me - I really appreciate it.
I update the issue and possibly close it then, if that's alright :) - I personally still think it should be a separate option if you want to display a value vs it being nullable.

[Kapim]

Hello, any news on this issue? optionalEmitDefaultValues parameter is still ignored.

[sdoeringNew]

This whole behaviour of omitting values is fatal.

We use a request validation on the server side and fields - marked as required - are missing because those values are either 0 or false. Those requests are rejected because they are invalid. And the request validation is right - required fields have to be there.

Therefore:
I plead for handle this issue as an error.
And the default value for the optionalEmitDefaultValues shall be true.

[sdoeringNew]

Had anyone time to look at the pull request?