Thank you,
this is now clear.

On Wed, 07 Mar 2018 22:19:51 GMT, Sönke Ludwig wrote:

On Wed, 07 Mar 2018 21:52:04 GMT, FraMecca wrote:

I have another question concerning the following constraint from the wiki:

layered on top is a (more or less) 0.8.1 compatible high level API, using structs instead of classes to enable a scoped API without requiring all users to add scope to their request handlers

Which class needs to be changed?

I think that porting HTTPServerRequest and HTTPServerResponse to structs requires a change to the rest of the api, in particular the requestHandler provided by the user, to accept references to req and ref thus breaking the compatibility with the previous api.

The idea is that the struct is passed by value and contains a pointer to the actual data as a private member. The fields would be represented by properties returning scope data, so that once DIP1000 has made it into mainline, no data can escape the request handler. After [some recent discussion][1], this turned out to be the only viable option to get performance, safety and backwards compatibility together.

struct HTTPServerRequest {
   private HTTPServerRequestData* m_data;

   @property scope string requestURI() const { return m_data.requestURI; }