Initial Support for swift 4

[csantanapr]

Initial Support for Swift 4 using current python proxy
Same approach as 3.1.1 just using swift 4 runtime and new set of packages

[csantanapr]

The idea is to get this out with same API interface as 3.1.1 this allows users to start using swift4 ASAP.
Then we can see how can we have an implementation that we can have a new API function definition to allow better handling using Codable and dong async with completion handler

[jthomas]

💯 on Swift 4 support. Swift 4 adds lots of new features (Codable support) that making writing server-side Swift much easier.

Does it make sense to separate the re-factoring of the handler from the runtime release? Codable support is one of the main features in Swift 4 and it will be a much better developer experience if this feature is supported from the beginning. How would you migrate users between what look like breaking API changes if they are introduced separately?

I think it would make more sense to release both features together.

[csantanapr]

It would not a be a braking change, in and out dictionary will still work.

Yes I think we can brake it into smaller chunks and do it in a way we can do it in stages.

1. swift 4 with current signature (dictionary in, dictionary out) using python proxy
2. swift 4 with codable signature (codable in, handler(codable out, codable error) proxy
3. swift 4 with swift web proxy

I think we can get both 1&2 together. but they can be separate. I just got started and got 1 working, I can get that merge into master if that make sense.
then start work on 2 on top of that

[csantanapr]

In terms of User experience they I want to make it dead simple
dict in dict out

func main(args: [String:Any]) -> [String:Any] {
   return args
}

codable

struct Employee: Codable {
  let id: Int
  let name: String
}
func main(input: Employee, respondWith: (Employee?, RequestError?) -> Void) -> Void {
    respondWith(input, nil)
}

deployment looks the same for both

wsk action create helloAction hello.swift --kind swift:4
wsk action invoke helloAction -p id 42 -p name Carlos -r
{
  "id":42,
  "name":Carlos
}

epilogue.swift will handle how to call the function based on signature.

[ianpartridge]

Could we use a Result type here?

enum Result<T, E: Swift.Error> {
    case success(T)
    case failure(E)
}

enum OpenWhiskError: Swift.Error {
    case barf
    // etc
}

struct Employee: Codable {
    let id: Int
    let name: String
}

func main(input: Employee, respondWith: (Result<Employee, OpenWhiskError>) -> Void) -> Void {
    respondWith(.success(input))
}

[ianpartridge]

Or even keep the args/return model with:

func main(input: Employee) -> Result<Employee, OpenWhiskError> {
    return .success(input)
}

and main() would be defined as

func main<T, E>(input: T) -> Result<T, E> {
    ...
}

[rolivieri]

As @csantanapr mentioned in https://github.com/apache/incubator-openwhisk-runtime-swift/issues/3#issue-271889325 and https://github.com/apache/incubator-openwhisk-runtime-swift/issues/3#issuecomment-342535030, I am also thinking we should first provide/release basic Swift 4 support in OpenWhisk. By basic, I mean allowing developers to implement functions using Swift 4 and use the same entry point (API) that exists today: a dictionary IN, a dictionary OUT. Doing so would allow developers migrate their existing actions to Swift 4 without too much effort (non-breaking API change).

Then, as a separate and second release for Swift 4, we can introduce one or more new entry points (i.e. APIs) that Swift developers can leverage in addition to the basic dictionary IN, dictionary OUT. These new APIs will leverage the Codable protocol that is available now in Swift 4. For instance, one new API method could allow developers specify a Codable IN and a Codable OUT, and this Codable OUT object would be made available through a callback function, hence supporting async APIs out of the box (which more than likely will be the norm for fetching data from external resources during the execution of an action). @csantanapr and I spent time this past week prototyping how this could look like (https://github.com/rolivieri/functions-swift/blob/master/Sources/Action/main.swift).

We are still getting user feedback from the community in regards to the new Codable APIs and we should spend more time looking at web actions and figure out what set of Codable APIs should be made available for Swift developers (regular and web actions). While we work on defining these APIs, we could (in parallel) now make available Swift 4 with the known, existing API: a dictionary IN, a dictionary OUT.

To sum up, I am thinking we can use two stages/milestones for Swift 4: 1) Swift 4 support with existing API and 2) new set of APIs that leverage Codable.