[swift-server-dev] Prototype of the discussed HTTP API Spec

Johannes Weiss johannesweiss at apple.com
Tue May 30 10:05:09 CDT 2017

Hi Paulo,

> On 30 May 2017, at 4:00 pm, Paulo Faria <paulo at zewo.io> wrote:
> Regarding that. I'm fine with not providing synchronous APIs, right now. As long as we design the APIs in a way that adding those later becomes natural. (I *really* *really* hope we get support for coroutines in Swift 5). That's my only concern.

so do I. But see it this way: Foundation and the whole ecosystem is _full_ of APIs that take async continuation blocks/closures. So whatever the Swift concurrency model will look like, I'm sure there's be a transition path. Also: The Swift concurrency model won't just appear, at some point that'll be discussed on swift-{evo,dev} and you're more than welcome to pitch in!

> About the undefined behaviour regarding setjmp/longjmp. Interestingly, I've been using libmill/libdill (provides coroutines with context switching using assembly instead of setjmp/longjmp) with Zewo for the past 2 years. And we never once had a problem with that.

Yes, I'm aware of that but that can change any day and there might already be cases where it doesn't work. Don't get me wrong, I personally like this programming model but we won't be able to pitch this to swift-evo as it's currently officially UB as Joe confirms.


More information about the swift-server-dev mailing list