[Fishrock123]

Alternative to
#642

This approach is more flexible but requires the user ensure that their
state implements/derives Clone, or is wrapped in an Arc.

Co-authored-by: Jacob Rothstein hi@jbr.me

Notably while this has less new API surface, this requires more from user code.

[Fishrock123]

I was on the edge about it, but i should have said in my OP: "Is non-Arc Clone" actually what a user would expect?"

I'm not sure it is personally? Like, your state will not actually be shared between anything at all if it's not an Arc - it will only contain the data set originally and set within any specific request. That isn't "shared" state in any sense. If this is really for shared state I'm not honestly sure this is the correct direction...

[yoshuawuyts]

"Is non-Arc Clone" actually what a user would expect?"

I think so; this is not an uncommon thing to provide, and think it's entirely reasonable thing to allow people to implement. Certain performance sensitive applications may actually want this degree of control, and empowering them to implement this is useful.

For example: you could imagine someone only has State to pass config from the CLI into the app. Instead of putting it behind an atomic reference, it may just be faster to copy values. Not having an Arc at all is useful, and just slapping #[derive(Clone)] on State would be a great solution.

[Fishrock123]

Updated as per suggestions. 😄

[jbr]

lgtm! my only nit is that since the examples are didactic, we might want to set an example of doing

// examples/upload.rs
type State = Arc<TempDir>;
/*snip*/
.put(|req: Request<State>| async move {

or create a State struct, like https://github.com/jbr/tide-example/blob/master/src/main.rs#L7-L19.

[Fishrock123]

Updated that example... i think there is a bit more work to do on the examples more generally outside of this PR.