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

HList try_pluck #197

Open
whatisaphone opened this issue Jul 28, 2022 · 2 comments
Open

HList try_pluck #197

whatisaphone opened this issue Jul 28, 2022 · 2 comments

Comments

@whatisaphone
Copy link

I had a go at writing a try_pluck method on HList. It would return Some if the type is in the list, or None if it isn't. But I wasn't able to make it work due to rustc complaining about conflicting impls. My gut tells me this would need specialization on nightly, but I could be wrong about that. Do you have any thoughts/ideas?

@ExpHP
Copy link
Collaborator

ExpHP commented Jul 30, 2022

Hmmmm. Yes I can see why this would raise conflicting impls. The thing that makes pluck possible is that, if an HList contains only one copy of T, then there is exactly one applicable impl.

For try_pluck, there doesn't seem to be any way to write an impl for the None case that would not be applicable to all HLists. This will always lead to a conflict with the "Some" case. (or to a type inference error for the Index type, which could either be the "found" index or a "not found" index (probably the length of the list))

Specialization in rust has had such a tumultuous history that I'm always wary of suggestions that it may help a particular problem. If it does work for this, then it would have to take the place of our index types, since those currently would disambiguate the impls and cause them to not specialize each other.
(and getting rid of the index types would be a nice outcome...)

@lloydmeta
Copy link
Owner

I agree with @ExpHP 's assessment; this will be pretty difficult to implement with HList. I do wonder though : what is the use case for such a method, when HList is statically typed? Would it make sense to use something dynamically typed like the way actix extensions is using TypeId?

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

3 participants