Clarify how to handle default value on non-nullable optional properties when "default" keyword is not specified

[ahmednfwela]

Related OpenAPITools/openapi-generator#10972

Spec version: 3.0.3
the spec doesn't indicate how to handle model properties in the following case:

required: false
nullable: false
type: xxxxx

• required: false means that the property might not exist in the json
• nullable: false means that the property doesn't accept null as a value

so what to do when the spec document doesn't specify the default keyword ?

1. assume default is null (works only for properties where nullable: true, otherwise it will break the spec)

2. assume default to be of same type as type, so for non-nullable types that would be
   "boolean" => false
   "object" => { }
   "array" => [ ]
   "number"/"integer" => 0
   "string" => ""

3. make it required to specify the default keyword when required: false and nullable: false

4. ignore the provided required: false and assume instead required: true

5. ignore the provided nullable: false and assume nullable: true

[webron]

Not sure I follow the issue here (and I tried checking the linked issue as well). Why is the default relevant at all in this case? If it doesn't exist, there's just no default value. It doesn't affect what kind of type is supported.

[hkosova]

@webron Example: given this schema

type: object
required: [foo]
properties:
  foo:
    type: string
  bar:       # <--- Optional property without a default value defined
    type: string

and the payload {"foo": "test"}, what value for bar should the consumer of this payload assume when deserializing this payload?

[webron]

From the given definition, it doesn't necessarily matter. The assumption of:

"boolean" => false
"object" => { }
"array" => [ ]
"number"/"integer" => 0
"string" => ""

isn't necessarily true either, and can be language-dependent. Even if a user can't pass null, it doesn't mean the value stored on the other side can't be assumed to be null to signify an non-value. You can also say that having no value means it just doesn't exist (so, there's a potential default value, a null value or a no value).

[webron]

I did reply before noticing the edited example, but I think the answer stands. Please let me know if you feel otherwise.

[ahmednfwela]

@webron I edited the issue to add your opinion as option 5

however the choice is, I think this is causing enough confusion in statically typed languages that it needs to be clarified

[handrews]

@ahmednfwela if there's no default there's no default. In some languages that makes sense, as the field can be completely omitted, or set to some sort of undefined value that is distinct from null. In other languages, that doesn't make sense. This is a feature, not a bug: it exists to for the benefit of environments where it is useful. If it is not useful in your environment, then it should not be used. If an API provider is using it anyway, you should ask them what their intent is (assuming they want to support statically typed clients).