Skip to content

Change Service::call to take &self #3040

Closed
@seanmonstar

Description

@seanmonstar

Now that hyper defines its own Service trait (#2853), there's a key part we should clarify before hitting 1.0 Final: Should it take &self or &mut self? Whichever the decision, the why should be documented (not necessarily in the API docs, but in code comments or in the docs/ folder).

The usual arguments are here:

  • &self
    • It prepares the way for async fn, since then the future only borrows &self, and thus a Service can concurrently handle multiple outstanding requests at once.
    • It's clearer that Services can likely be cloned.
  • &mut self
    • If a Service has state (usually per-connection), it's cheaper to mutate it on each connection. Not being &mut would require internal synchronization.

I'm happy to open it up to discussion here. I'd recommend that comments are arguments be well-formed and reasoned, and try to provide something new, so that we keep the signal high. Chat is a fine place to bounce an idea around, and then come back and write it up so we can keep the history (decision history is extremely valuable).

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-serverArea: server.B-breaking-changeBlocked: this is an "API breaking change".C-featureCategory: feature. This is adding a new feature.E-easyEffort: easy. A task that would be a great starting point for a new contributor.

    Type

    No type

    Projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions