Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

src: move State off of Request (WIP) #645

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

Fishrock123
Copy link
Member

@Fishrock123 Fishrock123 commented Jul 13, 2020

error[E0119]: conflicting implementations of trait `endpoint::Endpoint<_>`:
  --> src\endpoint.rs:70:1
   |
54 | / impl<State, F, Fut, Res> Endpoint<State> for F
55 | | where
56 | |     State: Send + Sync + 'static,
57 | |     F: Send + Sync + 'static + Fn(Request) -> Fut,
...  |
67 | |     }
68 | | }
   | |_- first implementation here
69 |
70 | / impl<State, F, Fut, Res> Endpoint<State> for F
71 | | where
72 | |     State: Send + Sync + 'static,
73 | |     F: Send + Sync + 'static + Fn(Request, State) -> Fut,
...  |
83 | |     }
84 | | }
   | |_^ conflicting implementation

Not sure I understand this error. F should be a distinct type for both?? Note: the difference is in F and those compiler messages don't show enough lines for that.

error[E0119]: conflicting implementations of trait `endpoint::Endpoint<_>`:
  --> src\endpoint.rs:70:1
   |
54 | / impl<State, F, Fut, Res> Endpoint<State> for F
55 | | where
56 | |     State: Send + Sync + 'static,
57 | |     F: Send + Sync + 'static + Fn(Request) -> Fut,
...  |
67 | |     }
68 | | }
   | |_- first implementation here
69 |
70 | / impl<State, F, Fut, Res> Endpoint<State> for F
71 | | where
72 | |     State: Send + Sync + 'static,
73 | |     F: Send + Sync + 'static + Fn(Request, State) -> Fut,
...  |
83 | |     }
84 | | }
   | |_^ conflicting implementation
@tirr-c
Copy link
Collaborator

tirr-c commented Jul 13, 2020

I guess the compiler thinks F might implement both Fn(Request) -> Fut and Fn(Request, State) -> Fut. You can make such a type with #![feature(fn_traits, unboxed_closures)] by manually implementing Fn and its supertraits.

Copy link
Member

@yoshuawuyts yoshuawuyts left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As per #643 (comment) this is not a direction I feel comfortable with, and I would prefer we see #642 through.

@Fishrock123
Copy link
Member Author

Err... this isn't solving the issue that #642 and #644 solve... this is just general ergonomics, imo? Likewise see #643 (comment)

@yoshuawuyts
Copy link
Member

One interesting implication of this PR is that it would've made #670 easier to implement; no State means no Default either.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants