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

The return type http_body_util::Collected::aggregate is unnamable #134

Open
MOZGIII opened this issue Dec 5, 2024 · 2 comments
Open

The return type http_body_util::Collected::aggregate is unnamable #134

MOZGIII opened this issue Dec 5, 2024 · 2 comments

Comments

@MOZGIII
Copy link

MOZGIII commented Dec 5, 2024

pub fn aggregate(self) -> impl Buf {
    self.bufs
}

Can we turn impl Buf into a namable type (BufList<B>)? It is nice to use impl Buf and all, but today it makes it impossible to use it as a trait associated type.

Example:

trait Bufferer {
    type Data: bytes::Buf;

    // ...
}

impl<B> Bufferer for Collected<B> {
    type Data = ?; // can't just `impl Buf` now
}
@seanmonstar
Copy link
Member

Yes, it is unnameable. It should eventually be possible to use ATPIT, and in the meantime it's possible to box the type, or convert it into a different one (like copy_to_bytes).

@MOZGIII
Copy link
Author

MOZGIII commented Dec 6, 2024

Thx for the reply! Yep, both solutions work. I can't decide for myself which one to use now, so I now have an overengineered a solution on my end of the code to support both variants...

Can I ask why is the API like this in the first place? It is quite obvious doing this today before rust fully support referring to existential types creates a needless burden for the end user. There is an obvious solution to the problem - that is to just use a nameable type there. Not sure what is the benefit here, but it does make people waste time working around this issue.


UPD: also, should I make a PR to change the impl Buf to a named type?

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

No branches or pull requests

2 participants