Move Before,After to utils

[yoshuawuyts]

Moves the Before and After structs out of the top level and into a utils submodule. I was looking over the docs, and noticed that it was kind of hard to find what we needed -- this cleans it up somewhat. We expect that Before and After will eventually be replaced by language features, so this might be a reasonable stop-gap.

[jbr]

This seems totally reasonable, although utils has the same "kitchen drawer" concern as misc, etc and contrib. What about tide::middleware::{Before, After}?

[yoshuawuyts]

@jbr heh yeah we talked about it — and you're entirely right. I feel "middleware" is fairly similar though; but with the added fact it would only hold certain kinds of middleware but not others could make it even more confusing. E.g. cookies and logging middleware are part of their own logical submodules.

Maybe the docs for "utils" should mention it's for utilities that fill holes in the language/stdlib only? So that we make sure that we are least expect to be able to remove them eventually?

[Fishrock123]

I would be ok with tide::middleware::{Before, After, Middleware} while also keeping tide::Middleware as a shortcut.

after thinking more, I really think my above suggestion would be best

[yoshuawuyts]

after thinking more, I really think my above suggestion would be best

@Fishrock123 I don't really know how to reply to this. You're not explaining why you think this is best. Nor are you engaging with the earlier conversation of using "utils" over "middleware" and what we can do to overcome potential downsides. It doesn't just not add to the conversation, it actively prevents us from making progress.

I would like to move this issue forward, but there is now pushback without any path to concensus. We've reached a decision deadlock here, and this is exactly the kind of situation we need to avoid.

[Fishrock123]

@yoshuawuyts Ah you're right, thanks for pointing out that I should re-read the above.

Would you mind the point what language feature we expect this will eventually be replaced by though?

[yoshuawuyts]

Would you mind the point what language feature we expect this will eventually be replaced by though?

@Fishrock123 async closures. We need a definition of smth like AsyncFn/AsyncFnMut that knows how to reason about borrows.