New generator swift5

[4brunu]

PR checklist

• Read the contribution guidelines.
• Ran the shell script under ./bin/ to update Petstore sample so that CIs can verify the change. (For instance, only need to run ./bin/{LANG}-petstore.sh, ./bin/openapi3/{LANG}-petstore.sh if updating the {LANG} (e.g. php, ruby, python, etc) code generator or {LANG} client's mustache templates). Windows batch files can be found in .\bin\windows\. If contributing template-only or documentation-only changes which will change sample output, be sure to build the project first.
• Filed the PR against the correct branch: master, 4.1.x, 5.0.x. Default: master.
• Copied the technical committee to review the pull request if your PR is targeting a particular programming language.

@jgavris (2017/07) @ehyche (2017/08) @Edubits (2017/09) @jaz-ah (2017/09) @d-date (2018/03)

Description of the PR

This PR adds basic support for Swift 5 and it lowers the barrier of any Swift 5 contribution.
It's basically a copy of the Swift 4 generator, but it adds support for Swift Package Manager (fix #4057), updates the dependencies version.

EDIT:
I have updated this PR to introduce some new features in along side with the new Swift 5 generator.
The new features that the Swift 5 generator has, compared with the Swift 4 generator are:

• Add nullable (or x-nullable in OAS2) support. This will replace the unwrapRequired option.
• Add support for URLSession
• Date formatter add support for ISO8601 with and without milliseconds (fixes [SWIFT4] JSON Decoding fails to parse all valid date-time values #699 and it's a continuation of [Swift4] Support both OpenAPI "date-time" variants (Fix for 699) #1454)
• make enums conform to CaseIterable (fixes [REQ][Swift] make Enum's conform to CaseIterable protocol #4842)
• Add support for Combine framework
• cocoapods remove deprecated docset_url and add watchos deployment target
• Add ability to pass in a dedicated queue for processing network response (Fix for [Swift 4] Add ability to pass in a dedicated queue for processing network response #230)

This PR fixes #2721

[d-date]

@4brunu Thanks for contribution but we plan to make another generator which reduce dependencies. #4086

Since Xcode 11 has officially released so I restart to work on. Sorry for late work.

[4brunu]

@d-date No problem 🙂
Can you elaborate on which dependencies are you removing? Is is Alamofire or another one?
Looking forward to it.
Do you have an idea on when are you planing to finish it?
Should I delete this PR?

[wing328]

Like other generators such as Java, Ruby that are more mature, I foresee Swift 5 generators will support the library option for different HTTP libraries so my take is to accept this one before anyone has time to add the library option for this Swift 5 generator.

[d-date]

@wing328 I don't agree with you. IMO, all dependencies should be removed since no more maintain so many templates for response types and APIClients.
We should provide only interfaces and models.

[d-date]

@4brunu I'm trying to remove all dependencies including Alamofire since this client shouldn't have any dependencies. We want to select own API Clients and response type, including Combine, by myself.

Instead, in other repository, we should provide example API Client for users so we can focus on implementing OAS itself.

We Swift developers hope to make this generator stable for reducing developing time.

[wing328]

I see what you mean. I can only share my experience working on this project. You will always find users who want to use a particular HTTP library: Java client now supports 10+ HTTP libraries: feign, okhttp, Dart supports 2 or 3 via different generators. TS supports a lot via different generators.

Besides Alamofire, there's another one by IBM: https://github.com/IBM-Swift/SwiftyRequest

I'm not surprised if we are going to see a request from the user to support SwiftyRequest in the not too distant future.

My take is to support a swappable ApiClient class from day one and leave it up to the user to choose which HTTP library they want to use.

(and it's perfectly fine we disagree on different things)

[4brunu]

@d-date I also prefer to reduce the number of dependencies, so it would be nice to rely on URLSession instead of Alamofire and I even considered creating a PR that removes Alamofire.

But on the other hand I think it would be nice to provide an optional integration with `RxSwift.

My concern with a big new Swift 5 generator is how long it will take, because we could introduce so many improvements, Result, Combine, URLSession, etc, that can take a long time.

This PR actually doesn't provide any value in itself, because it's the same as in Swift 4, but it will lower the barrier to anyone that wants to contribute with improvements to the Swift 5 generator.

What do you think of a more incremental approach?

By the way, I'm totally ok closing this PR 🙂

[tovkal]

I would merge this as is. My current use case is: I am using Swagger 2 until now, with Swift 5, and want to update to Swagger 3. So I just want to update the Swagger version while keeping the rest as it is.

I understand that there is room for improvement (decoupling from networking dependencies, adding other networking options) but I too believe this should be delivered incrementally.

[wing328]

IMPORTANT

This generator is relatively new and being actively developed. It's considered as beta/alpha and there will be breaking changes (new features, bug fixes, etc) to this generator without further notice.