[swift-server-dev] Next HTTP API meeting

[Michael Chiu]

I think we’re going around circles in the mailing list on type vs semantic. I personally prefer to have a protocol interface and also a default concrete type, for the concrete type I’ll prefer value type but reference semantic or hybrid implementation. 

As discussed in the second meeting, value type != value semantic and reference type != reference semantic.
https://github.com/swift-server/work-group/blob/master/meetings/http/2016-12-12/minutes.md <https://github.com/swift-server/work-group/blob/master/meetings/http/2016-12-12/minutes.md>

 
> 
> It’s very simple.
> You want to retrieve data for the response from external service ( for example Redis ) asynchronously. ( Asynchronously because you don’t want to block request handlers just to wait for the data ).
> You cannot do it if Request and Response were structs. You cannot retain them inside Redis-callback closures.
> 

Yes in this case inout won’t work for obvious reason but you can actually retain them in the callback closure as long as it has some class member, we can always write getters and setters. In fact making the it value type we can leverage inout argument to reduce the overhead of ARC since inout captures the struct in the stack.

In fact, making the req/res value type make it safer from accidental mutations. In order to mutate the struct in the callback closure, end user will have to do something like { var res = $0 } in the closure, and the mutating and nonmutating keywords can only use on value types. (And it comes for free in swift, no external protocol needed) 

> How do you suggest to allocate struct on the heap? using UnsafePointers ? and how is that any better than using class if you want to achieve Reference semantics ?
If personally I’m building a framework, I’ll always prefer UnsafePointer of heap allocate structs to achieve reference semantics, with maybe some Unmanaged for classes. But the goal we’ve now is to build utilities for building frameworks. 

UnsafeMutablePointers<struct> has the following benefits over class and Unmanaged<class>:
- no ARC // with Unmanaged you still have to manage the counting yourself
- able to use third party allocator
- Maybe even external garbage collector
- C/C++ data structure friendly

> 
> I believe issues related to using structs mentioned by Logan were similar to your example:
> 
> fun addConstMiddleware(middleware: (Request) -> ())
> 
> Here, if request is a struct, it will be copied for each middleware, and instead of one ARC increment we will need to copy the request itself + increment all the reference counts for its  properties.
> 
> Now, if it was a class and we wanted to create a read-only function for that, we could easily create a protocol that has only { get } access to properties,
> 
> protocol ImmutableRequest {
> 	var headers: … { get }
> }
> 
> Request: ImmutableRequest 
> 
> fun addConstMiddleware(middleware: (ImmutableRequest) -> ())
> 

It depends on the semantic. If the struct is a reference semantically designed it has only the size of a few pointers, which is much less expensive than the ARC overhead.


> As I see from these emails,  one of the main reasons for using struct is to avoid ARC overhead and this can be understood. Still we want to use struct but at the same time want all the functions ( responder chain ) to be able to change it. That sounds like a Reference semantic to me.
> 
> If we can prove that ARC overhead is significant and there is no way to optimise it, probably the good way would be to use structs. Then, frameworks like Kitura/Perfect… can wrap the struct in a class and pass it to a responder chain.

Actually if we really do want to avoid ARC overhead on classes we can use Unmanaged<class> as well. Wrap the struct in a class is basically identical to class so it doesn’t make too much sense to me. 


Michael.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-server-dev/attachments/20170328/3bdbff47/attachment.html>