fn update_pet_with_form(&self, pet_id: i64, name: Option<&str>, status: Option<&str>) -> Result<(), Error> {
    let configuration: &configuration::Configuration = self.configuration.borrow();
    let client = &configuration.client;

    let uri_str = format!("{}/pet/{petId}", configuration.base_path, petId=pet_id);
    let mut req_builder = client.post(uri_str.as_str());

    if let Some(ref user_agent) = configuration.user_agent {
        req_builder = req_builder.header(reqwest::header::USER_AGENT, user_agent.clone());
    }
    if let Some(ref token) = configuration.oauth_access_token {
        req_builder = req_builder.bearer_auth(token.to_owned());
    };
    let mut form_params = std::collections::HashMap::new();
    form_params.insert("name", name.to_string());
    form_params.insert("status", status.to_string());
    req_builder = req_builder.form(&form_params);

Doing some more testing, it looks like this has issues due to the Option on the form parameters. Curious if anyone has input on a better way to address this: seems like I could either add the same changes to the form parameters as well or break the operation parameters into queryParams and formParams.

Hi @jonahgeorge,

IMO, this PR is a must have. I already forked it for one of my projects and it gave expected results.
Thanks a lot.

I think you forgot to regenerate OpenAPI generator general doocumentation, which explain the CI failure for your PR. The new parameter have to be added to this documentation (rust.md file).

@jonahgeorge thanks for the PR.

Instead of introducing a new option, what about using nullable instead? We've done that in some other clients, e.g.

@wing328 Agree that using nullable is a better approach. I wasn't aware that variable is exposed to the templates (besides looking at other languages, is there an easy way to see what is passed in?).

Also, wouldn't it still be considered a breaking change to make nullable=true fields use Option<T> if they aren't right now and require a feature flag?

Agree that using nullable is a better approach. I wasn't aware that variable is exposed to the templates (besides looking at other languages, is there an easy way to see what is passed in?).

You can use -DdebugOperations, which will show its value (boolean)

Also, wouldn't it still be considered a breaking change to make nullable=true fields use Option if they aren't right now and require a feature flag?

To me, it's more like correcting the behavior. For other languages/generators, we do not consider it as a breaking change but of course, I like your suggestion to give a proper heads-up to the user and how they can use nullable (OAS3) or x-nullable (OAS2) to control the behavior.

Any news for this PR?

If nobody is working on it anymore, I can try to fix it…

@bcourtine please kindly go ahead. What about merging it into a branch (in this project) so that more people can work on it?

Sorry for the radio silence, I haven't had time to polish this up.
@bcourtine if you want to take it over, go for it

Hello @wing328 @jonahgeorge

I completed this PR and proposed a new one here: #4016

IMO, it should be mergeable (hyper/reqwest sample code compiles without error).

PR #4016 (which includes and completes this one) has been merged. So this PR can be closed.