Change HBRequest/HBResponse to struct

[adam-fowler]

Made HBRequest and HBResponse structs. This should make moving to a full async/await implementation a little easier as they become automatically Sendable as long as all their members are Sendable.

For most situations, code changes related to HBResponse becoming a struct involves making a mutable instance of the response.

It is slightly more complex for HBRequest. HBRequest is large enough such that converting it to a struct actually reduces performance. To fix this I have moved all the parameters of HBRequest that are read only into an internal class. There is no point copying all this data through all the response generators. Storing it in a class means only a reference to the data is passed through.

Having HBRequest as a struct also means some APIs that would have edited the request have had to change. You can see this in changes to hummingbird-auth

[codecov]

Codecov Report

Merging #96 (327a27c) into main (5990e7e) will increase coverage by 0.16%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main      #96      +/-   ##
==========================================
+ Coverage   82.40%   82.57%   +0.16%     
==========================================
  Files          53       53              
  Lines        2574     2599      +25     
==========================================
+ Hits         2121     2146      +25     
  Misses        453      453              

Impacted Files	Coverage Δ
Sources/Hummingbird/Server/Response.swift	100.00% <ø> (ø)
...ources/Hummingbird/Middleware/CORSMiddleware.swift	93.47% <100.00%> (+0.14%)	⬆️
Sources/Hummingbird/Router/ResponseGenerator.swift	100.00% <100.00%> (ø)
Sources/Hummingbird/Router/RouterMethods.swift	93.15% <100.00%> (+0.39%)	⬆️
Sources/Hummingbird/Router/TrieRouter.swift	94.82% <100.00%> (+0.09%)	⬆️
...Hummingbird/Server/Application+HTTPResponder.swift	100.00% <100.00%> (ø)
Sources/Hummingbird/Server/Request.swift	96.36% <100.00%> (+1.62%)	⬆️
Sources/Hummingbird/Server/ResponsePatch.swift	85.71% <100.00%> (ø)
...mmingbirdFoundation/Cookies/Response+Cookies.swift	100.00% <100.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 5990e7e...327a27c. Read the comment docs.

[adam-fowler]

@mcritz do you have any thoughts on this? Would like to get other people to have a look before I commit to this

[mcritz]

@adam-fowler I’ll take some time to look into this. My first thought is that if this is a breaking change, then it absolutely means a major version bump.

Todo:

• Pull the branch
• Create a simple POC
• Report back results / opinions

[mcritz]

@adam-fowler I think it works OK. And from an application developer perspective, I suppose its all an implementation detail. But the HBRequest.Internal type feels heavy.

What specifically is motivating the change? Are these types going to be changed to Actor or something?

[adam-fowler]

@mcritz The main motivation behind the changes is to avoid race conditions. With HBRequest being a class it can be accessed/changed from multiple threads at the same time. Changing it to a struct avoids this.

The change to a struct does have a performance cost, but by moving all the read only values into the internal class Internal I have managed to avoid this cost.

Much of this work has been inspired by the requirements for the Sendable conformance requirements for objects passed into async/await functions. See the Swift proposal. It is preparing for a full Swift concurrency implementation of Hummingbird, but it is still valid work even without that implementation as it improves stability.

[adam-fowler]

@adam-fowler I’ll take some time to look into this. My first thought is that if this is a breaking change, then it absolutely means a major version bump.

Given we haven't gone 1.0 yet, we haven't committed to a interface and don't really need a major bump before releasing this. Swift concurrency may force other changes on us and I don't want to go up to v1.0 prior to that.

[mcritz]

Gotcha! Cool