[Rust] Support default values for model properties

[ThomasVille]

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

The Rust client generator (rust) does not currently support the default schema element for model properties. When a property has a default value defined in the OpenAPI specification, the generated Rust model ignores it and falls back to Rust's #[derive(Default)], which uses None for Option<T> types.

For example, the petstore.yaml spec defines the Order schema with complete: default: false:

Order:
  type: object
  properties:
    id:
      type: integer
      format: int64
    petId:
      type: integer
      format: int64
    quantity:
      type: integer
      format: int32
    shipDate:
      type: string
      format: date-time
    status:
      type: string
      description: Order Status
      enum:
        - placed
        - approved
        - delivered
    complete:
      type: boolean
      default: false

The generated Rust model ignores this default:

#[derive(Clone, Default, Debug, PartialEq, Serialize, Deserialize)]
pub struct Order {
    #[serde(rename = "id", skip_serializing_if = "Option::is_none")]
    pub id: Option<i64>,
    #[serde(rename = "petId", skip_serializing_if = "Option::is_none")]
    pub pet_id: Option<i64>,
    #[serde(rename = "quantity", skip_serializing_if = "Option::is_none")]
    pub quantity: Option<i32>,
    #[serde(rename = "shipDate", skip_serializing_if = "Option::is_none")]
    pub ship_date: Option<String>,
    #[serde(rename = "status", skip_serializing_if = "Option::is_none")]
    pub status: Option<Status>,
    #[serde(rename = "complete", skip_serializing_if = "Option::is_none")]
    pub complete: Option<bool>,
}

This means Order::default().complete returns None instead of Some(false), and deserializing JSON with a missing complete field also yields None.

In contrast, the Python generator correctly handles this default:

complete: Optional[StrictBool] = False

Describe the solution you'd like

Generate a custom Default implementation and add #[serde(default)] at the struct level when any property has a default value:

#[derive(Clone, Debug, PartialEq, Serialize, Deserialize)]
#[serde(default)]
pub struct Order {
    #[serde(rename = "id", skip_serializing_if = "Option::is_none")]
    pub id: Option<i64>,
    #[serde(rename = "petId", skip_serializing_if = "Option::is_none")]
    pub pet_id: Option<i64>,
    #[serde(rename = "quantity", skip_serializing_if = "Option::is_none")]
    pub quantity: Option<i32>,
    #[serde(rename = "shipDate", skip_serializing_if = "Option::is_none")]
    pub ship_date: Option<String>,
    #[serde(rename = "status", skip_serializing_if = "Option::is_none")]
    pub status: Option<Status>,
    #[serde(rename = "complete", skip_serializing_if = "Option::is_none")]
    pub complete: Option<bool>,
}

impl Default for Order {
    fn default() -> Self {
        Self {
            id: None,
            pet_id: None,
            quantity: None,
            ship_date: None,
            status: None,
            complete: Some(false),
        }
    }
}

The #[serde(default)] attribute ensures that during deserialization, missing fields are populated from Order::default() rather than using None.

Describe alternatives you've considered

1. Per-field #[serde(default = "fn_name")]: This works but requires generating a separate function for each field with a default, leading to more verbose output. The struct-level #[serde(default)] approach is cleaner.

2. Post-processing the generated code: Users could manually edit the generated models, but this breaks on regeneration and defeats the purpose of code generation.

Additional context

Type mapping for defaults:

Type	OpenAPI default	Rust default expression
string	"foo"	Some("foo".to_string())
integer	42	Some(42)
number	1.234	Some(1.234)
boolean	false	Some(false)
enum	placed	Some(Status::Placed)
array	["a", "b"]	Some(vec!["a".to_string(), "b".to_string()])

Related issues:

• #3359 - [ASP.NET Core] Support default values for model properties
• #14013 - [go-server] enforcement of minimum, maximum; application of default

I'd be happy to work on a PR to implement this feature.

[Mattias-Sehlstedt]

What is the background for wanting the generated client to submit the default value that is present in a specification?

The purpose of the default is for the server to specify a fallback that is used if the client does not submit a value. So the correct behavior is to send nothing if you as a client do not specifically want to state a certain value, and then that the server interprets the absence as their specified fallback.

If the client themselves sends the default value, then it will not be able to react to a change of default that the server might make. This may result in incorrect behavior, since the actual indented behavior of your application is most likely to follow the servers default value, rather than "hard coding" it to the default seen at the time of client code generation (because if you did not want to follow the default, you would always explicitly state a value).

Comment taken from previous answer on the subject here.

[ThomasVille]

@Mattias-Sehlstedt Thanks for the response, I didn't see it that way.

The background in my case is this issue: #22344 where, if we specify a discriminator on a oneOf field, then the behavior of serde is to remove this field from the struct, so the discriminator cannot appear in the different models referenced by oneOf:

{
  "openapi": "3.1.0",
  "info": {
    "title": "Test",
    "description": "Reproduction scenario",
    "version": "0.68.0"
  },
  "components": {
    "schemas": {
      "PersonResource": {
        "type": "object",
        "required": ["type", "id"],
        "properties": {
          "type": { // In the Rust SDK, this field will cause a runtime error because `serde` will remove it thanks to the `#[serde(tag)]` directive.
            "type": "string",
            "enum": ["person"]
          },
          "id": {
            "type": "string"
          },
          "name": {
            "type": "string"
          }
        }
      },
      "OrganizationResource": {
        "type": "object",
        "required": ["type", "id"],
        "properties": {
          "type": { // In the Rust SDK, this field will cause a runtime error because `serde` will remove it thanks to the `#[serde(tag)]` directive.
            "type": "string",
            "enum": ["organization"]
          },
          "id": {
            "type": "string"
          },
          "companyName": {
            "type": "string"
          }
        }
      },
      "ResourceUnion": {
        "oneOf": [
          {
            "$ref": "#/components/schemas/PersonResource"
          },
          {
            "$ref": "#/components/schemas/OrganizationResource"
          }
        ],
        "discriminator": {
          "propertyName": "type",
          "mapping": {
            "person": "#/components/schemas/PersonResource",
            "organization": "#/components/schemas/OrganizationResource"
          }
        }
      }
    }
  },
  "paths": {}
}

A workaround to that issue is this very issue where, if we could specify a default value for type (like in other targets), then serde wouldn't complain.

Note that this will likely always happen with APIs that implement JSON:API because the included field returned by the API must contain actual ResourceObjects which have the same structure (so #[serde(untagged)] doesn't work) and must contain the type field.

[Mattias-Sehlstedt]

I am interpreting that the suggestion is that the specification should then become

{
  ...
  "OrganizationResource": {
    "type": "object",
    "required": [
      "type",
      "id"
    ],
    "properties": {
      "type": {
        "type": "string",
        "enum": [
          "organization"
        ],
        "default": "organization"
      },
      "id": {
        "type": "string"
      },
      "companyName": {
        "type": "string"
      }
    }
  },
  ...
}

In order to handle the issue. Is this a correct understanding of what the finished solution would be?

[ThomasVille]

Yes, that would be it. But the concerns you raised seem valid. Maybe supporting default values in the client is not a good idea.

So we could instead fix #22344 with the same solution as in https://github.com/OpenAPITools/openapi-generator/pull/20336/files#diff-65ac10dbd17d504a693204ee67db573f9c0514af4b07970cfcfb2b7a0f5f7450 (for Reqwest instead of Axum), and drop this issue entirely.

[Mattias-Sehlstedt]

Yes another approach is necessary. Using such an approach would encourage specification providers to misuse the OpenApi specification in order to get a specific behavior from the Rust client.

The proper approach is to let the client generation make some extra assumptions in the generation about oneOf models, and solve it entirely in the openapi-generator. So similarly to what your linked issue has done.

[ThomasVille]

Thanks for your feedback, I'll close this issue then.