[jarrodparkes]

Attempts to solve #11033

This PR adds a new property vendor extension x-null-encodable for use with the swift5 generator. If set to true, then the generated properties will use the NullEncodable<Wrapped> type:

public enum NullEncodable<Wrapped> {
    case encodeNothing
    case encodeNull
    case encodeValue(Wrapped)
}

This type gives the client full control of whether to encode a value/null -OR- encode nothing.

PR checklist

• Read the contribution guidelines.
• If contributing template-only or documentation-only changes which will change sample output, build the project before.
• Run the shell script(s) under ./bin/ (or Windows batch scripts under.\bin\windows) to update Petstore samples related to your fix. This is important, as CI jobs will verify all generator outputs of your HEAD commit, and these must match the expectations made by your contribution. You only need to run ./bin/{LANG}-petstore.sh, ./bin/openapi3/{LANG}-petstore.sh if updating the code or mustache templates for a language ({LANG}) (e.g. php, ruby, python, etc).
• File the PR against the correct branch: master, 4.3.x, 5.0.x. Default: master.
• Copy the technical committee to review the pull request if your PR is targeting a particular programming language.

Core Team Members

@jgavris
@ehyche
@Edubits
@jaz-ah
@4brunu

[4brunu]

@jarrodparkes one question, this only applies to properties that can be nil or applies to all properties?
I left some comments, that are just to start a discussing, to understand what should be the right behavior

[jarrodparkes]

@4brunu

this only applies to properties that can be nil or applies to all properties?

This behavior applies to properties earmarked as x-null-encodable in the spec. Properties with this extension are encoded into the new NullEncodable type which gives clients the flexibility to encode a value, encode null, or encode nothing for the property. This is different than our current behaviors...

1. A property that is nullable and required will always be encoded regardless of its value
2. A property that is nullable will only be encoded when the value is non-nil

[4brunu]

So this will basically override/ignore the nullable and required, right?

[jarrodparkes]

@4brunu yeh, more or less. the spec example doesn't make that clear because x-null-encodable is used alongside nullable and required. but, to your point, x-null-encodable essentially overrides them

[jarrodparkes]

@4brunu I was able to restore the default values 👍 let me know what you think

[4brunu]

@jarrodparkes overall this looks good to me, I just left some small comments on some improvements/questions

[4brunu]

CI is failing, but it looks like it's not related to this PR.
Could you please close and reopen this PR please, to restart the CI?

[jarrodparkes]

@4brunu sure thing

[4brunu]

That's weird the CI failed again with a different error this time, that is still not related to this PR (I think)

[jarrodparkes]

That's weird the CI failed again with a different error this time, that is still not related to this PR (I think)

@4brunu yeh, seems like that might be an issue across a few different PRs.

@wing328 still curious, if you might have some insights on the following...

TL;DR - In postProcessModels we inject a custom property vendorExtension called x-null-encodable-default-value. However, x-null-encodable-default-value doesn't appear to be present/usable in the model_doc.mustache template. Looking at DefaultGenerator.java it seems that the model documentation is resolved AFTER postProcessModels, so perhaps we aren't using something correctly in the mustache template? Any help would be greatly appreciated.

[jarrodparkes]

@4brunu let me know if there anything else you need to see here. AFAIK the failed check isn't related to this PR

[wing328]

Restarted the bitrise job. Let's see how that goes.

[wing328]

bitrise job passed via https://app.bitrise.io/build/6c82ea06-8680-4bd4-8079-b94726e9ea98

[4brunu]

Looks good to me 👍

[jarrodparkes]

anything holding this up @4brunu @wing328 ?